Replace NIP-EE with Marmot (#2154)

58.md

@@ -11,7 +11,7 @@ user profiles:
 
 1. A "Badge Definition" event is defined as an addressable event with kind `30009` having a `d` tag with a value that uniquely identifies the badge (e.g. `bravery`) published by the badge issuer. Badge definitions can be updated.
 
-2. A "Badge Award" event is a kind `8` event with a single `a` tag referencing a "Badge Definition" event and one or more `p` tags, one for each pubkey the badge issuer wishes to award. Awarded badges are immutable and non-transferrable.
+2. A "Badge Award" event is a kind `8` event with a single `a` tag referencing a "Badge Definition" event and one or more `p` tags, one for each pubkey the badge issuer wishes to award. Awarded badges are immutable and non-transferable.
 
 3. A "Profile Badges" event is defined as an _addressable event_ with kind `30008` with a `d` tag with the value `profile_badges`.
 Profile badges contain an ordered list of pairs of `a` and `e` tags referencing a `Badge Definition` and a `Badge Award` for each badge to be displayed.

63.md

@@ -1,82 +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
-}
-```
-
-### 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?

C0.md

@@ -25,7 +25,7 @@ The `.content` field contains the actual code snippet text.
 - `runtime` - Runtime or environment specification (e.g., "node v18.15.0", "python 3.11")
 - `license` - License under which the code (along with any related data contained within the event, when available, such as the description) is shared. This MUST be a standard [SPDX](https://spdx.org/licenses/) short identifier (e.g., "MIT", "GPL-3.0-or-later", "Apache-2.0") when available. An additional parameter containing a reference to the actual text of the license MAY be provided. This tag can be repeated, to indicate multi-licensing, allowing recipients to use the code under any license of choosing among the referenced ones
 - `dep` - Dependency required for the code to run (can be repeated)
-- `repo` - Reference to a repository where this code originates. This MUST be a either standard URL or, alternatively, the address of a [NIP-34](34.md) Git repository annoucement event in the form `"30617:<32-bytes hex a pubkey>:<d tag value>"`. If a repository announcement is referenced, a recommended relay URL where to find the event should be provided as an additional parameter
+- `repo` - Reference to a repository where this code originates. This MUST be a either standard URL or, alternatively, the address of a [NIP-34](34.md) Git repository announcement event in the form `"30617:<32-bytes hex a pubkey>:<d tag value>"`. If a repository announcement is referenced, a recommended relay URL where to find the event should be provided as an additional parameter
 
 ## Format
 

EE.md

@@ -1,10 +1,12 @@
+> __Warning__  `unrecommended`: superseded by the [Marmot Protocol](https://github.com/marmot-protocol/marmot)
+
 NIP-EE
 ======
 
 E2EE Messaging using the Messaging Layer Security (MLS) Protocol
 ----------------------------------------------------------------
 
-`draft` `optional`
+`final` `unrecommended` `optional`
 
 This NIP standardizes how to use the [MLS Protocol](https://www.rfc-editor.org/rfc/rfc9420.html) with Nostr for efficient and E2EE (end-to-end encrypted) direct and group messaging.
 

README.md

@@ -108,7 +108,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-BE: Nostr BLE Communications Protocol](BE.md)
 - [NIP-C0: Code Snippets](C0.md)
 - [NIP-C7: Chats](C7.md)
-- [NIP-EE: E2EE Messaging using MLS Protocol](EE.md)
+- [NIP-EE: E2EE Messaging using MLS Protocol](EE.md) --- **unrecommended**: superseded by the [Marmot Protocol](https://github.com/marmot-protocol/marmot)
 
 ## Event Kinds
 | kind          | description                     | NIP                                    |
@@ -135,9 +135,9 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `21`          | Video Event                     | [71](71.md)                            |
 | `22`          | Short-form Portrait Video Event | [71](71.md)                            |
 | `30`          | internal reference              | [NKBIP-03]                             |
-| `31`          | external web reference          | [NKBIP-03]                            |
-| `32`          | hardcopy reference              | [NKBIP-03]                            |
-| `33`          | prompt reference                | [NKBIP-03]                            |
+| `31`          | external web reference          | [NKBIP-03]                             |
+| `32`          | hardcopy reference              | [NKBIP-03]                             |
+| `33`          | prompt reference                | [NKBIP-03]                             |
 | `40`          | Channel Creation                | [28](28.md)                            |
 | `41`          | Channel Metadata                | [28](28.md)                            |
 | `42`          | Channel Message                 | [28](28.md)                            |
@@ -145,9 +145,9 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `44`          | Channel Mute User               | [28](28.md)                            |
 | `62`          | Request to Vanish               | [62](62.md)                            |
 | `64`          | Chess (PGN)                     | [64](64.md)                            |
-| `443`         | KeyPackage                      | [EE](EE.md)                            |
-| `444`         | Welcome Message                 | [EE](EE.md)                            |
-| `445`         | Group Event                     | [EE](EE.md)                            |
+| `443`         | KeyPackage                      | [Marmot](marmot)                       |
+| `444`         | Welcome Message                 | [Marmot](marmot)                       |
+| `445`         | Group Event                     | [Marmot](marmot)                       |
 | `818`         | Merge Requests                  | [54](54.md)                            |
 | `1018`        | Poll Response                   | [88](88.md)                            |
 | `1021`        | Bid                             | [15](15.md)                            |
@@ -209,7 +209,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `10020`       | Media follows                   | [51](51.md)                            |
 | `10030`       | User emoji list                 | [51](51.md)                            |
 | `10050`       | Relay list to receive DMs       | [51](51.md), [17](17.md)               |
-| `10051`       | KeyPackage Relays List          | [EE](EE.md)                            |
+| `10051`       | KeyPackage Relays List          | [Marmot](marmot)                       |
 | `10063`       | User server list                | [Blossom][blossom]                     |
 | `10096`       | File storage server list        | [96](96.md) (deprecated)               |
 | `10166`       | Relay Monitor Announcement      | [66](66.md)                            |
@@ -296,6 +296,8 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 [Tidal-nostr]: https://wikistr.com/tidal-nostr
 [geocaching]: https://nostrhub.io/naddr1qvzqqqrcvypzppscgyy746fhmrt0nq955z6xmf80pkvrat0yq0hpknqtd00z8z68qqgkwet0vdskx6rfdenj6etkv4h8guc6gs5y5
 [nostr-epoxy]: https://github.com/Origami74/nostr-epoxy-reverse-proxy
+[marmot]: https://github.com/marmot-protocol/marmot
+
 
 ## Message types