add optional announcement with payment url.

18.md

@@ -21,9 +21,9 @@ reposted.
 
 ## Quote Reposts
 
-Mentions to [NIP-21](21.md) entities like `nevent`, `note` and `naddr` on any 
-event must be converted into `q` tags. The `q` tag ensures quote reposts are 
-not pulled and included as replies in threads. It also allows you to easily 
+Mentions to [NIP-21](21.md) entities like `nevent`, `note` and `naddr` on any
+event must be converted into `q` tags. The `q` tag ensures quote reposts are
+not pulled and included as replies in threads. It also allows you to easily
 pull and count all of the quotes for a post. The syntax follows
 
 `["q", "<event-id> or <event-address>", "<relay-url>", "<pubkey-if-a-regular-event>"]`
@@ -36,3 +36,10 @@ as a "generic repost", that can include any kind of event inside other than
 
 `kind 16` reposts SHOULD contain a `"k"` tag with the stringified kind number
 of the reposted event as its value.
+
+When reposting a replaceable event, the repost SHOULD include an `"a"` tag with
+the event coordinate (`kind:pubkey:d-tag`) of the reposted event.
+
+If the `"a"` tag is not present, it indicates that a specific version of a replaceable
+event is being reposted, in which case the `content` field must contain the full
+JSON string of the reposted event.

51.md

@@ -26,7 +26,7 @@ For example, _mute list_ can contain the public keys of spammers and bad actors
 | Mute list         | 10000 | things the user doesn't want to see in their feeds          | `"p"` (pubkeys), `"t"` (hashtags), `"word"` (lowercase string), `"e"` (threads)                     |
 | Pinned notes      | 10001 | events the user intends to showcase in their profile page   | `"e"` (kind:1 notes)                                                                                |
 | Read/write relays | 10002 | where a user publishes to and where they expect mentions    | see [NIP-65](65.md)                                                                                 |
-| Bookmarks         | 10003 | uncategorized, "global" list of things a user wants to save | `"e"` (kind:1 notes), `"a"` (kind:30023 articles), `"t"` (hashtags), `"r"` (URLs)                   |
+| Bookmarks         | 10003 | uncategorized, "global" list of things a user wants to save | `"e"` (kind:1 notes), `"a"` (kind:30023 articles)                   |
 | Communities       | 10004 | [NIP-72](72.md) communities the user belongs to             | `"a"` (kind:34550 community definitions)                                                            |
 | Public chats      | 10005 | [NIP-28](28.md) chat channels the user is in                | `"e"` (kind:40 channel definitions)                                                                 |
 | Blocked relays    | 10006 | relays clients should never connect to                      | `"relay"` (relay URLs)                                                                              |

63.md

@@ -0,0 +1,82 @@
+NIP-63
+======
+
+Relay-based Paywalls
+--------------------
+
+`draft` `optional`
+
+This NIP specifies how relays can support _paywalled content_. Well, "paywall" is a misnomer as this NIP doesn't imply payment necessarily, it's agnostic about that, so better call it **premium content**.
+
+The idea is that a _content-creator_ should be able to manage a list of _premium-reader_ who have access to their premium content, then choose some specific relays to publish their content based on their known support for this NIP.
+
+Relays that support this NIP (as they could indicate in their [NIP-11](11.md) responses) should receive the list of users and use it together with [NIP-42](42.md) authentication in order to decide what content will be readable by each requester.
+
+### Premium event
+
+Any event can be premium, all it needs is a [NIP-70](70.md) `["-"]` tag and another tag `["nip63"]` that clearly indicates its situation.
+
+Because normal relays won't care about these tags it's enough for the _content-creator_ to release the event to these relays in order to make it "public" to everybody.
+
+### Membership Event
+
+Membership events must be sent directly to the relays that will implement the paywall. By default relays should not serve these events to anyone, only to the _content-creator_ directly. Because of this, these lists can be kept reasonably private as long as the _content-creator_ is discrete in their publishing, but can also be made public by being published to other relays.
+
+The lists are constituted of one event for each _premium-reader_, and their removal/update must be done with a [NIP-09](09.md) deletion request.
+
+```yaml
+{
+  "kind": 1163,
+  "pubkey": "<content-creator>",
+  "tags": [
+    ["p", "<premium-reader>"]
+  ],
+  // ...other fields
+}
+```
+
+### Relay behavior
+
+A relay that implements this NIP should:
+
+- signal `63` in its `supported_nips` NIP-11 field;
+- accept `kind:1163` events and not serve them to anyone except to their creator;
+- accept deletion requests for such events;
+- accept premium events containing `["-"]` and `["nip63"]` tags only from their creator;
+- only serve the premium events to users that have a matching `kind:1163`;
+- serve an `AUTH` challenge to any client opening a connection immediately.
+
+### Client behavior
+
+A client doesn't have to do much in order to access premium content: if a client is already very liberal with its authentication policies it will automatically perform NIP-42 AUTH whenever it connects to the relay; otherwise it may want to check if such relay supports `63` before deciding.
+
+After that, any `REQ`s should include premium content automatically and transparently. This means that while constructiing a normal "following" feed a client will get the premium content automatically and place it in front of the user.
+
+A client may decide to display these events differently if they have the `["nip63"]` tag.
+
+### Announcement
+
+Optionally a _content-creator_ can announce that they have premium content available by publishing an event:
+
+```
+{
+  "kind": 10163,
+  "content": "<something about the premium content, the price and other stuff, optionally>",
+  "tags": [
+    ["url", "<payment-page-url>"]
+  ]
+}
+```
+
+Where `<payment-page-url>` is a normal webpage that may have anything in it. From there on, payments are handled off-protocol. The entity that handled the payment is expected to somehow modify the list of _premium-readers_ or enable the user to modify it later.
+
+#### Zap relationship
+
+This NIP is payment agnostic, but that doesn't mean one shouldn't use zaps or nutzaps for this. Clients or third-party services may offer a feature to read all zaps, compute their sums according to any criteria and use that information to modify the list of _premium-readers_.
+
+### Future additions
+
+- more private list membership: perhaps doing an HMAC with the public key of the reader and a key that is shared with the relays will be enough for this.
+- tiered membership: custom tiers for fine-grained content access control can be added by adding more tags to the `kind:1163` event and more items to the `["nip63"]` tag.
+- teaser events: perhaps a `["nip63", "teaser"]` special tag could cause an event to be displayed only to those that do not have access to its premium counterpart, this would also be managed by the relay.
+- relays for premium content different from the outbox relays?

EE.md

@@ -1,6 +1,8 @@
-# NIP-EE
+NIP-EE
+======
 
-## E2EE Messaging using the Messaging Layer Security (MLS) Protocol
+E2EE Messaging using the Messaging Layer Security (MLS) Protocol
+----------------------------------------------------------------
 
 `draft` `optional`