allow referencing existing lists as members.

Co-authored-by: arthurfranca <arthur.a.franca@gmail.com>

29.md

@@ -120,21 +120,21 @@ Clients can send these events to a relay in order to accomplish a moderation act
 
 Each moderation action uses a different kind and requires different arguments, which are given as tags. These are defined in the following table:
 
-| kind | name                | tags                                           |
-| ---  | ---                 | ---                                            |
-| 9000 | `put-user`          | `p` with pubkey hex and optional roles         |
-| 9001 | `remove-user`       | `p` with pubkey hex                            |
-| 9002 | `edit-metadata`     | fields from `kind:39000` to be modified        |
-| 9005 | `delete-event`      | `e` with event id hex                          |
-| 9007 | `create-group`      |                                                |
-| 9008 | `delete-group`      |                                                |
-| 9009 | `create-invite`     |                                                |
+| kind | name            | tags                                                                             |
+| ---  | ---             | ---                                                                              |
+| 9000 | `put-user`      | `p` with pubkey hex and optional roles                                           |
+| 9001 | `remove-user`   | `p` with pubkey hex                                                              |
+| 9002 | `edit-metadata` | fields to be modified, and optionally `unrestricted`, `open`, `visible` `public` |
+| 9005 | `delete-event`  | `e` with event id hex                                                            |
+| 9007 | `create-group`  |                                                                                  |
+| 9008 | `delete-group`  |                                                                                  |
+| 9009 | `create-invite` | arbitrary `code`                                                                 |
 
 It's expected that the group state (of who is an allowed member or not, who is an admin and with which permission or not, what are the group name and picture etc) can be fully reconstructed from the canonical sequence of these events.
 
 ### Group metadata events
 
-These events contain the group id in a `d` tag instead of the `h` tag. They MUST be created by the relay master key only and a single instance of each (or none) should exist at all times for each group. They are merely informative but should reflect the latest group state (as it was changed by moderation events over time).
+These events contain the group id in a `d` tag instead of the `h` tag. They MUST be created by the relay master key only (as stated by the [NIP-11](11.md) `"self"` pubkey) and a single instance of each (or none) should exist at all times for each group. They are merely informative but should reflect the latest group state (as it was changed by moderation events over time).
 
 - *group metadata* (`kind:39000`) (optional)
 

46.md

@@ -97,18 +97,25 @@ Each of the following are methods that the _client_ sends to the _remote-signer_
 
 | Command                  | Params                                                                        | Result                                                                 |
 | ------------------------ | -------------------------------------------------                             | ---------------------------------------------------------------------- |
-| `connect`                | `[<remote-signer-pubkey>, <optional_secret>, <optional_requested_permissions>]`        | "ack" OR `<required-secret-value>`                                                                  |
+| `connect`                | `[<remote-signer-pubkey>, <optional_secret>, <optional_requested_perms>]`     | `"ack"` OR `<required-secret-value>`                                   |
 | `sign_event`             | `[<{kind, content, tags, created_at}>]`                                       | `json_stringified(<signed_event>)`                                     |
-| `ping`                   | `[]`                                                                          | "pong"                                                                 |
-| `get_public_key`         | `[]`                                                                          | `<user-pubkey>`                                                         |
+| `ping`                   | `[]`                                                                          | `"pong"`                                                               |
+| `get_public_key`         | `[]`                                                                          | `<user-pubkey>`                                                        |
 | `nip04_encrypt`          | `[<third_party_pubkey>, <plaintext_to_encrypt>]`                              | `<nip04_ciphertext>`                                                   |
 | `nip04_decrypt`          | `[<third_party_pubkey>, <nip04_ciphertext_to_decrypt>]`                       | `<plaintext>`                                                          |
 | `nip44_encrypt`          | `[<third_party_pubkey>, <plaintext_to_encrypt>]`                              | `<nip44_ciphertext>`                                                   |
 | `nip44_decrypt`          | `[<third_party_pubkey>, <nip44_ciphertext_to_decrypt>]`                       | `<plaintext>`                                                          |
+| `switch_relays`          | `[]`                                                                          | `["<relay-url>", "<relay-url>", ...]` OR `null`                        |
 
 ### Requested permissions
 
-The `connect` method may be provided with `optional_requested_permissions` for user convenience. The permissions are a comma-separated list of `method[:params]`, i.e. `nip44_encrypt,sign_event:4` meaning permissions to call `nip44_encrypt` and to call `sign_event` with `kind:4`. Optional parameter for `sign_event` is the kind number, parameters for other methods are to be defined later. Same permission format may be used for `perms` field of `metadata` in `nostrconnect://` string.
+The `connect` method may be provided with `optional_requested_perms` for user convenience. The permissions are a comma-separated list of `method[:params]`, i.e. `nip44_encrypt,sign_event:4` meaning permissions to call `nip44_encrypt` and to call `sign_event` with `kind:4`. Optional parameter for `sign_event` is the kind number, parameters for other methods are to be defined later. Same permission format may be used for `perms` field of `metadata` in `nostrconnect://` string.
+
+### Switching relays
+
+At all times, the _remote-signer_ should be in control of what relays are being used for the connection between it and the _client_. Therefore it should be possible for it to evolve its set of relays over time as old relays go out of operation and new ones appear. Even more importantly, in the case of the connection initiated by the _client_ the client may pick relays completely foreign to the _remote-signer_'s preferences, so it must be possible for it to switch those immediately.
+
+Therefore, compliant clients should send a `switch_relays` request immediately upon establishing a connection (always, or at reasonable intervals). Upon receiving such requests, the _remote-signer_ should reply with its updated list of relays, or `null` if there is nothing to be changed. Immediately upon receiving an updated relay list, the _client_ should update its local state and send further requests on the new relays. The `remote-signer` should then be free to disconnect from the previous relays if that is desired.
 
 ## Response Events `kind:24133`
 

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

85.md

@@ -0,0 +1,132 @@
+NIP-85
+======
+
+Trusted Assertions
+------------------
+
+`draft` `optional`
+
+Certain Webs of Trust calculations require access to a large volume of events and/or computing power, making it virtually impossible to perform them directly on clients. This NIP allows users to offload such calculations to declared trusted service providers, and for these providers to publish signed "Trusted Assertion" events for the user client's consumption.
+
+## Assertion Events
+
+Trusted Assertions are always addressable (replaceable) events with the `d` tag pointing to the "subject" of the assertion. This NIP currently recognizes three distinct target "subjects" on which such calculations can be performed: *pubkeys*, *regular events*, and *addressable events*. Each subject type is mapped to an event kind: 
+
+| Subject            | Event Kind     | `d` tag value     |
+| ------------------ | -------------- | ----------------- |
+| User               | 30382          | `<pubkey>`        |
+| Event              | 30383          | `<event_id>`      |
+| Addressable Event  | 30384          | `<event_address>` |
+| NIP-73 Identifier  | 30385          | `<i-tag>`         | 
+
+Calculation results are saved in pre-defined tags whose syntax and semantics are agreed upon by providers and clients. 
+
+Example of ranking a pubkey with a web of trust score of `89`: 
+
+```jsonc
+{
+  "kind": 30382,
+  "tags": [
+    ["d", "e88a691e98d9987c964521dff60025f60700378a4879180dcbbb4a5027850411"], // target user's public key
+    ["rank", "89"],
+  ],
+  "content": "",
+  //...
+}
+```
+
+## Kind 30382: Users as Subject: 
+
+The following result types have been declared:
+
+| Result type             | Tag name               | Tag value format  |
+| ----------------------- | ---------------------- | ----------------- |
+| Follower Count          | `followers`            | int               |
+| User Rank               | `rank`                 | int, norm 0-100   |
+| First Post Time         | `first_created_at`     | unix timestamp    | 
+| Post Count              | `post_cnt`             | int               | 
+| Reply Count             | `reply_cnt`            | int               | 
+| Reactions Count         | `reactions_cnt`        | int               |
+| Zap Amount Received     | `zap_amt_recd`         | int, sats         |
+| Zap Amount Sent         | `zap_amt_sent`         | int, sats         | 
+| Zap Number Received     | `zap_cnt_recd`         | int               |
+| Zap Number Sent         | `zap_cnt_sent`         | int               |
+| Avg Zap Amount/day recd | `zap_avg_amt_day_recd` | int, sats         |
+| Avg Zap Amount/day sent | `zap_avg_amt_day_sent` | int, sats         |
+| Reports Received        | `reports_cnt_recd`     | int               |
+| Reports Sent            | `reports_cnt_sent`     | int               |
+| Common Topics           | `t`                    | string            |
+| Generally active start  | `active_hours_start`   | int, 0-24, UTC    |
+| Generally active end    | `active_hours_end`     | int, 0-24, UTC    |
+
+Each provider can offer their own ways to calculate such values. For instance, the Follower Count of one trust provider might remove the user's muted public keys while another provider keeps them. Users can then choose how they want to see this information in their preferred client by picking a provider that aligns with their view. 
+
+## Kind 30383: Events as Subject
+
+Providers can rate individual events with the following tags:  
+
+| Result type             | Tag name               | Tag value format  |
+| ----------------------- | ---------------------- | ----------------- |
+| Event Rank              | `rank`                 | int, norm 0-100   | 
+| Event Comment Count     | `comment_cnt`          | int               |
+| Event Quote Count       | `quote_cnt`            | int               |
+| Event Repost Count      | `repost_cnt`           | int               |
+| Event Reaction Count    | `reaction_cnt`         | int               |
+| Event Zap Count         | `zap_cnt`              | int               |     
+| Event Zap Amount        | `zap_amount`           | int, sats         |
+
+## Kind 30384: Addressables as Subject
+
+Providers can rate all versions of addressable events using the following tags: 
+
+| Result type               | Tag name               | Tag value format  |
+| ------------------------- | ---------------------- | ----------------- |
+| Address Rank              | `rank`                 | int, norm 0-100   | 
+| Address Comment Count     | `comment_cnt`          | int               |
+| Address Quote Count       | `quote_cnt`            | int               |
+| Address Repost Count      | `repost_cnt`           | int               |
+| Address Reaction Count    | `reaction_cnt`         | int               |
+| Address Zap Count         | `zap_cnt`              | int               |     
+| Address Zap Amount        | `zap_amount`           | int, sats         |
+
+## Kind 30385: External identifier as Subject
+
+Providers can rate books, locations, movies, websites, and hashtags using [NIP-73](73.md) identifiers. 
+
+| Result type       | Tag name               | Tag value format  |
+| ----------------- | ---------------------- | ----------------- |
+| Rank              | `rank`                 | int, norm 0-100   | 
+| Comment Count     | `comment_cnt`          | int               |
+| Reaction Count    | `reaction_cnt`         | int               |
+
+NIP-73 `k` tags should be added to the event as well.
+
+## Declaring Trusted Service Providers
+
+Kind `10040` lists the user's authorized providers for each result. Each `kind:tag` is followed by the `pubkey` of the service and the relay where the results are published. Users can specify these publicly or privately by JSON-stringifying and encrypting the tag list in the `.content` using NIP-44. 
+
+```js
+{
+  "kind": 10040,
+  "tags": [
+    ["30382:rank", "4fd5e210530e4f6b2cb083795834bfe5108324f1ed9f00ab73b9e8fcfe5f12fe", "wss://nip85.nostr.band"],
+    ["30382:rank", "3d842afecd5e293f28b6627933704a3fb8ce153aa91d790ab11f6a752d44a42d", "wss://nostr.wine"],
+    ["30382:zap_amt_sent", "4fd5e210530e4f6b2cb083795834bfe5108324f1ed9f00ab73b9e8fcfe5f12fe", "wss://nip85.nostr.band"],
+  ],
+  "content": nip44Encrypt(JSON.stringify([
+    ["30383:rank", "4fd5e210530e4f6b2cb083795834bfe5108324f1ed9f00ab73b9e8fcfe5f12fe", "wss://nip85.nostr.band"],
+    ["30384:rank", "4fd5e210530e4f6b2cb083795834bfe5108324f1ed9f00ab73b9e8fcfe5f12fe", "wss://nip85.nostr.band"],
+  ]),
+  //...
+}
+```
+
+If the provider offers several algorithms or multiple points of view of an algorithm, the key listed in each tag SHOULD point to the key created for each algorithm or point of view. 
+
+## Final Considerations
+
+Service providers SHOULD update Trusted Assertions as fast as new information arrives, but only if the contents of each event actually change to avoid re-downloading the same information.
+
+Service providers MAY limit access to the results by using paid relays.
+
+In TAs, `p`, `e`, and `a` tags with the same value as the `d` tag MAY be used to add a relay hint to the home relay of that user or event.

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)                            |