allow referencing existing lists as members.

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.

73.md

@@ -18,6 +18,7 @@ There are certain established global content identifiers such as [Book ISBNs](ht
 | URLs                   | "`<URL, normalized, no fragment>`"                         | "web"                    |
 | Books                  | "isbn:`<id, without hyphens>`"                             | "isbn"                   |
 | Geohashes              | "geo:`<geohash, lowercase>`"                               | "geo"                    |
+| Countries              | "iso3166:`<code, uppercase>`"                              | "iso3166"                |
 | Movies                 | "isan:`<id, without version part>`"                        | "isan"                   |
 | Papers                 | "doi:`<id, lowercase>`"                                    | "doi"                    |
 | Hashtags               | "#`<topic, lowercase>`"                                    | "#"                      |
@@ -43,6 +44,21 @@ For the webpage "https://myblog.example.com/post/2012-03-27/hello-world" the "i"
 ]
 ```
 
+### Geohashes:
+
+- Geohash: `["i", "geo:ezs42e44yx96"]` - https://www.movable-type.co.uk/scripts/geohash.html
+
+Geohashes are a geocoding system that encodes geographic locations into short strings of letters and digits. They MUST be lowercase.
+
+### Countries:
+
+ISO 3166 codes can reference countries (ISO 3166-1 alpha-2) or subdivisions like states/provinces (ISO 3166-2).
+
+- Country (Venezuela): `["i", "iso3166:VE"]`
+- Subdivision (California, USA): `["i", "iso3166:US-CA"]`
+
+ISO 3166 codes MUST be uppercase. More info: https://en.wikipedia.org/wiki/ISO_3166
+
 ### Books:
 
 - Book ISBN: `["i", "isbn:9780765382030"]` - https://isbnsearch.org/isbn/9780765382030

README.md

@@ -92,6 +92,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-78: Application-specific data](78.md)
 - [NIP-7D: Threads](7D.md)
 - [NIP-84: Highlights](84.md)
+- [NIP-85: Trusted Assertions](85.md)
 - [NIP-86: Relay Management API](86.md)
 - [NIP-87: Ecash Mint Discoverability](87.md)
 - [NIP-88: Polls](88.md)
@@ -260,6 +261,9 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `30312`       | Interactive Room                | [53](53.md)                            |
 | `30313`       | Conference Event                | [53](53.md)                            |
 | `30315`       | User Statuses                   | [38](38.md)                            |
+| `30382`       | User Trusted Assertion          | [85](85.md)                            |
+| `30383`       | Event Trusted Assertion         | [85](85.md)                            |
+| `30384`       | Addressable Trusted Assertion   | [85](85.md)                            |
 | `30388`       | Slide Set                       | [Corny Chat][cornychat-slideset]       |
 | `30402`       | Classified Listing              | [99](99.md)                            |
 | `30403`       | Draft Classified Listing        | [99](99.md)                            |