allow referencing existing lists as members.

05.md

@@ -6,11 +6,11 @@ Mapping Nostr keys to DNS-based internet identifiers
 
 `final` `optional`
 
-On events of kind `0` (`user metadata`) one can specify the key `"nip05"` with an [internet identifier](https://datatracker.ietf.org/doc/html/rfc5322#section-3.4.1) (an email-like address) as the value. Although there is a link to a very liberal "internet identifier" specification above, the `<local-part>` part MUST only use characters `a-z0-9-_.`.
+On events of kind `0` (`user metadata`) one can specify the key `"nip05"` with an [internet identifier](https://datatracker.ietf.org/doc/html/rfc5322#section-3.4.1) (an email-like address) as the value. Although there is a link to a very liberal "internet identifier" specification above, NIP-05 assumes the `<local-part>` part will be restricted to the characters `a-z0-9-_.`, case-insensitive.
 
 Upon seeing that, the client splits the identifier into `<local-part>` and `<domain>` and use these values to make a GET request to `https://<domain>/.well-known/nostr.json?name=<local-part>`.
 
-The result should be a JSON document object with a key `"names"` that should then be a mapping of names to hex formatted public keys, in lowercase. If the public key for the given `<name>` matches the `pubkey` from the `user metadata` event, the client then concludes that the given pubkey can indeed be referenced by its identifier.
+The result should be a JSON document object with a key `"names"` that should then be a mapping of names to hex formatted public keys. If the public key for the given `<name>` matches the `pubkey` from the `user metadata` event, the client then concludes that the given pubkey can indeed be referenced by its identifier.
 
 ### Example
 
@@ -73,7 +73,7 @@ For example, if after finding that `bob@bob.com` has the public key `abc...def`,
 
 ### Public keys must be in hex format
 
-Keys must be returned in hex format, in lowercase. Keys in NIP-19 `npub` format are only meant to be used for display in client UIs, not in this NIP.
+Keys must be returned in hex format. Keys in NIP-19 `npub` format are only meant to be used for display in client UIs, not in this NIP.
 
 ### Showing just the domain as an identifier
 

22.md

@@ -192,7 +192,7 @@ A reply to a podcast comment:
     // this is a reference to the above comment
     ["e", "80c48d992a38f9c445b943a9c9f1010b396676013443765750431a9004bdac05", "wss://example.relay", "252f10c83610ebca1a059c0bae8255eba2f95be4d1d7bcfa89d7248a82d9f111"],
     // the parent comment kind
-    ["k", "1111"],
+    ["k", "1111"]
     ["p", "252f10c83610ebca1a059c0bae8255eba2f95be4d1d7bcfa89d7248a82d9f111"]
   ]
   // other fields

47.md

@@ -371,7 +371,7 @@ Response:
     "result_type": "lookup_invoice",
     "result": {
         "type": "incoming", // "incoming" for invoices, "outgoing" for payments
-        "state": "pending", // can be "pending", "settled", "accepted" (for hold invoices), "expired" (for invoices) or "failed" (for payments), optional
+        "state": "pending", // can be "pending", "settled", "expired" (for invoices) or "failed" (for payments), optional
         "invoice": "string", // encoded invoice, optional
         "description": "string", // invoice's description, optional
         "description_hash": "string", // invoice's description hash, optional
@@ -420,7 +420,7 @@ Response:
         "transactions": [
             {
                "type": "incoming", // "incoming" for invoices, "outgoing" for payments
-               "state": "pending", // can be "pending", "settled", "accepted" (for hold invoices), "expired" (for invoices) or "failed" (for payments), optional
+               "state": "pending", // can be "pending", "settled", "expired" (for invoices) or "failed" (for payments), optional
                "invoice": "string", // encoded invoice, optional
                "description": "string", // invoice's description, optional
                "description_hash": "string", // invoice's description hash, optional
@@ -485,89 +485,6 @@ Response:
 }
 ```
 
-### `make_hold_invoice`
-
-Creates a hold invoice using a pre-generated preimage.
-
-Request:
-```jsonc
-{
-    "method": "make_hold_invoice",
-    "params": {
-        "amount": 123, // value in msats
-        "description": "string", // invoice's description, optional
-        "description_hash": "string", // invoice's description hash, optional
-        "expiry": 213 // expiry in seconds from time invoice is created for a payment to be initiated, optional. This does not determine how long a payment can be held (see `settle_deadline`)
-        "payment_hash": "string" // Payment hash for the payment generated from the preimage
-        "min_cltv_expiry_delta": 144 // The minimum CLTV delta to use for the final hop, optional
-    }
-}
-```
-
-Response:
-```jsonc
-{
-    "result_type": "make_hold_invoice",
-    "result": {
-        "type": "incoming", // "incoming" for invoices, "outgoing" for payments
-        "invoice": "string", // encoded invoice, optional
-        "description": "string", // invoice's description, optional
-        "description_hash": "string", // invoice's description hash, optional
-        "payment_hash": "string", // Payment hash for the payment
-        "amount": 123, // value in msats
-        "created_at": unixtimestamp, // invoice/payment creation time
-        "expires_at": unixtimestamp, // invoice expiration time, optional if not applicable
-        "metadata": {} // generic metadata that can be used to add things like zap/boostagram details for a payer name/comment/etc.
-    }
-}
-```
-
-### `cancel_hold_invoice`
-
-Cancels a hold invoice using the payment hash
-
-Request:
-```jsonc
-{
-    "method": "cancel_hold_invoice",
-    "params": {
-        "payment_hash": "string" // Payment hash for the payment generated from the preimage
-    }
-}
-```
-
-Response:
-```jsonc
-{
-    "result_type": "cancel_hold_invoice",
-    "result": {}
-}
-```
-
-### `settle_hold_invoice`
-
-Settles a hold invoice using the preimage
-
-
-Request:
-```jsonc
-{
-    "method": "settle_hold_invoice",
-    "params": {
-        "preimage": "string" // preimage for the payment
-    }
-}
-```
-
-Response:
-```jsonc
-{
-    "result_type": "settle_hold_invoice",
-    "result": {}
-}
-```
-
-
 ## Notifications
 
 ### `payment_received`
@@ -622,30 +539,6 @@ Notification:
 }
 ```
 
-### `hold_invoice_accepted`
-
-Description: Sent when a payer accepts (locks in) a hold invoice. To avoid locking up funds in channels the hold invoice SHOULD be settled or canceled within a few minutes of receiving this event.
-
-Notification:
-```jsonc
-{
-    "notification_type": "hold_invoice_accepted",
-    "notification": {
-        "type": "incoming",
-        "state": "accepted",  // optional
-        "invoice": "string", // encoded invoice
-        "description": "string", // invoice's description, optional
-        "description_hash": "string", // invoice's description hash, optional
-        "payment_hash": "string", // Payment hash for the payment
-        "amount": 123, // value in msats
-        "created_at": unixtimestamp, // invoice/payment creation time
-        "expires_at": unixtimestamp, // invoice expiration time
-        "settle_deadline": blocknumber, // invoice can only be safely settled or canceled before this block number.
-        "metadata": {} // generic metadata that can be used to add things like zap/boostagram details for a payer name/comment/etc.
-    }
-}
-```
-
 ## Example pay invoice flow
 
 0. The user scans the QR code generated by the **wallet service** with their **client** application, they follow a `nostr+walletconnect://` deeplink or configure the connection details manually.
@@ -775,16 +668,6 @@ Here are some properties that are recognized by some NWC clients:
 }
 ```
 
-### Example Hold Invoice Support Flow
-
-1. Client generates a 32-byte hex-encoded preimage.
-2. Computes SHA-256 to derive payment hash.
-3. Sends `make_hold_invoice` with payment hash and desired parameters.
-4. Waits for `hold_invoice_accepted` notification.
-5. Upon receiving notification, either:
-
-   * Calls `settle_hold_invoice` with the original preimage to release funds, or
-   * Calls `cancel_hold_invoice` with payment hash to abort.
 ### Deep-links
 
 Wallet applications can register deeplinks in mobile systems to make it possible to create a linking UX that doesn't require the user scanning a QR code or pasting some code.

51.md

@@ -135,6 +135,7 @@ Some clients have used these lists in the past, but they should work on transiti
     ["e", "340e0326b340e0326b4941ed78ba340e0326b4941ed78ba340e0326b49ed78ba"], // PWA
     ["a", "32267:d6dc95542e18b8b7aec2f14610f55c335abebec76f3db9e58c254661d0593a0c:com.example.app"] // Reference to parent software application
   ],
+  "content": "Example App is a decentralized marketplace for apps",
   "sig": "a9a4e2192eede77e6c9d24ddfab95ba3ff7c03fbd07ad011fff245abea431fb4d3787c2d04aad001cb039cb8de91d83ce30e9a94f82ac3c5a2372aa1294a96bd"
 }
 ```

63.md

@@ -0,0 +1,102 @@
+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 discreet in his 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
+}
+```
+
+Besides marking individual public keys as readers it's also possible to tag a replaceable list, identified by its address:
+
+```yaml
+{
+  "kind": 1163,
+  "pubkey": "<content-creator>",
+  "tags": [
+    ["a", "<kind>:<pubkey>:<d-tag>"],
+  ],
+  // ...other fields
+}
+```
+
+This allows for an easy way to, for example, automatically mark all the people the _content-creator_ follows as allowed to read. Or people who are in a specific `kind:30000` follow-set.
+
+More importantly, it allows the _content-creator_ to delegate inclusion of readers to, for example, a payment provider, such that someone can pay and immediately become a _premium-reader_ without having to wait until the _content-creator_ is online again to update sign a new event.
+
+It remains a requirement that lists referenced in `"a"` tags here are sent directly to the relays that will implement the paywall, although such relays may try to fetch those in a best-effort basis.
+
+### 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 a tag like `["tier", "a"]` to the `kind:1163` event and using a `["nip63", "a"]` tag in the events, for example.
+- teaser events: perhaps a `["nip63", "", "-"]` (negative) 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?
+- individual "pay-per-view" content.