chore: small fixes (#2209)

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, NIP-05 assumes the `<local-part>` part will be restricted to the characters `a-z0-9-_.`, case-insensitive.
+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-_.`.
 
 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. 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, 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.
 
 ### 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. 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, in lowercase. 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

51.md

@@ -135,7 +135,6 @@ 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

@@ -1,102 +0,0 @@
-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.