add individual pay-per-view events as a future possibility.

29.md

@@ -83,7 +83,7 @@ Any user can send a kind `9021` event to the relay in order to request admission
 }
 ```
 
-The optional `code` tag may be used by the relay to preauthorize acceptance, together with the `kind:9009` `create-invite` moderation event.
+The optional `code` tag may be used by the relay to preauthorize acceptances in `closed` groups, together with the `kind:9009` `create-invite` moderation event.
 
 - *leave request* (`kind:9022`)
 
@@ -153,18 +153,14 @@ When this event is not found, clients may still connect to the group, but treat
     ["name", "Pizza Lovers"],
     ["picture", "https://pizza.com/pizza.png"],
     ["about", "a group for people who love pizza"],
-    ["private"],
+    ["public"], // or ["private"]
-    ["closed"]
+    ["open"] // or ["closed"]
   ]
   // other fields...
 }
 ```
 
-- `name`, `picture` and `about` are basic metadata for the group for display purposes.
+`name`, `picture` and `about` are basic metadata for the group for display purposes. `public` signals the group can be _read_ by anyone, while `private` signals that only AUTHed users can read. `open` signals that anyone can request to join and the request will be automatically granted, while `closed` signals that members must be pre-approved or that requests to join will be manually handled.
-- `private` indicates that only members can _read_ group messages. Omitting this tag indicates that anyone can read group messages.
-- `restricted` indicates that only members can _write_ messages to the group. Omitting this tag indicates that anyone can send messages to the group.
-- `hidden` indicates that relays should hide group metadata from non-members. Omitting this tag indicates that anyone can request group metadata events.
-- `closed` indicates that join requests are ignored. Omitting this tag indicates that users can expect join requests to be honored.
 
 - *group admins* (`kind:39001`) (optional)
 
@@ -235,7 +231,7 @@ The latest of either `kind:9000` or `kind:9001` events present in a group should
 
 ### Adding yourself to a group
 
-Anyone can send a `kind:9021` join request to a group. The relay may then generate a `kind:9000` event immediately, or defer that decision to an administator. If a group is `closed`, join requests are not honored unless they include an invite code.
+When a group is `open`, anyone can send a `kind:9021` event to it in order to be added, then expect a `kind:9000` event to be emitted confirming that the user was added. The same happens with `closed` groups, except in that case a user may only send a `kind:9021` if it has an invite code.
 
 ### Storing your list of groups
 

52.md

@@ -56,7 +56,7 @@ Example:
 
 ```yaml
 {
-  "id": <32-bytes lowercase hex-encoded SHA-256 of the serialized event data>,
+  "id": <32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>,
   "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
   "created_at": <unix timestamp in seconds>,
   "kind": 31922,

55.md

@@ -107,13 +107,6 @@ Send the Intent:
 launcher.launch(intent)
 ```
 
-### Initiating a connection
-
-- Client send a get_public_key `Intent`
-- Signer responds with the user `pubkey` and it's `packageName`
-- Client saves the `pubkey` and `packageName` somewhere and NEVER calls `get_public_key` again
-- Client now can send `content resolvers` and `Intents` for the other methods
-
 #### Methods
 
 - **get_public_key**
@@ -306,6 +299,33 @@ Clients SHOULD save the user pubkey locally and avoid calling the `get_public_ke
 
 #### Methods
 
+- **get_public_key**
+  - params:
+
+    ```kotlin
+    val result = context.contentResolver.query(
+        Uri.parse("content://com.example.signer.GET_PUBLIC_KEY"),
+        listOf(hex_pub_key),
+        null,
+        null,
+        null
+    )
+    ```
+  - result:
+    - Will return the **pubkey** in the result column
+
+      ```kotlin
+        if (result == null) return
+
+        if (it.getColumnIndex("rejected") > -1) return
+
+        if (result.moveToFirst()) {
+            val index = it.getColumnIndex("result")
+            if (index < 0) return
+            val pubkey = it.getString(index)
+        }
+      ```
+
 - **sign_event**
   - params:
 

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-transferable.
+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.
 
 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

@@ -0,0 +1,83 @@
+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?
+- individual "pay-per-view" content.

A4.md

@@ -1,56 +0,0 @@
-NIP-A4
-======
-
-Public Messages
----------------
-
-`draft` `optional`
-
-This NIP defines kind `24` as a simple plaintext message to one or more Nostr users. 
-
-The `.content` contains the message. `p` tags identify one or more receivers.
-
-```jsonc
-{
-  "pubkey": "<sender-pubkey>",
-  "kind": 24,
-  "tags": [
-    ["p", "<receiver>", "<relay-url>"],
-  ],
-  "content": "<message-in-plain-text>",
-}
-```
-
-Messages MUST be sent to the [NIP-65](65.md) inbox relays of each receiver and the outbox relay of the sender.
-
-Kind `24` is designed to be shown and replied to from notification screens. The goal is to allow clients to 
-support this feature without having to worry about chat history. There are no message chains. The concept of a 
-"thread", a "thread root", or a "chatroom" does not exist in this system, as messages can start and continue 
-without any syntactic connection to each other. `e` tags must not be used.
-
-This kind is not designed to be displayed on feeds, but anyone can see and reply to messages that may not be for them.
-
-## Advanced Support
-
-[NIP-40](40.md) `expiration` tags are recommended. Since there is no concept of a chatroom, it is unlikely that these messages will 
-make sense as time goes on.
-
-[NIP-18](18.md) quote repost `q` tags MAY be used when citing events in the `.content` with [NIP-21](21.md).
-
-```json
-["q", "<event-id> or <event-address>", "<relay-url>", "<pubkey-if-a-regular-event>"]
-```
-
-[NIP-25](25.md) reactions MUST add a `k` tag to `24`. 
-
-[NIP-57](57.md) zaps MUST include the `k` tag to `24`
-
-[NIP-21](21.md) links that use [NIP-19](19.md)'s `nevent1` MUST include a `kind` of `24`. Links that are not `kind:24` are not expected to be rendered natively by the client.
-
-[NIP-92](92.md) `imeta` tags SHOULD be added for image and video links.
-
-## Warnings
-
-There MUST be no expectation of privacy in this kind. It is just a public reply, but without a root note.
-
-Avoid confusing this kind with Kind `14` rumors in [NIP-17](17.md) DMs. This kind is signed and designed for public consumption.

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 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
+- `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
 
 ## Format
 

EE.md

@@ -1,12 +1,10 @@
-> __Warning__  `unrecommended`: superseded by the [Marmot Protocol](https://github.com/marmot-protocol/marmot)
-
 NIP-EE
 ======
 
 E2EE Messaging using the Messaging Layer Security (MLS) Protocol
 ----------------------------------------------------------------
 
-`final` `unrecommended` `optional`
+`draft` `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) --- **unrecommended**: superseded by the [Marmot Protocol](https://github.com/marmot-protocol/marmot)
+- [NIP-EE: E2EE Messaging using MLS Protocol](EE.md)
 
 ## Event Kinds
 | kind          | description                     | NIP                                    |
@@ -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                      | [Marmot](marmot)                       |
+| `443`         | KeyPackage                      | [EE](EE.md)                            |
-| `444`         | Welcome Message                 | [Marmot](marmot)                       |
+| `444`         | Welcome Message                 | [EE](EE.md)                            |
-| `445`         | Group Event                     | [Marmot](marmot)                       |
+| `445`         | Group Event                     | [EE](EE.md)                            |
 | `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          | [Marmot](marmot)                       |
+| `10051`       | KeyPackage Relays List          | [EE](EE.md)                            |
 | `10063`       | User server list                | [Blossom][blossom]                     |
 | `10096`       | File storage server list        | [96](96.md) (deprecated)               |
 | `10166`       | Relay Monitor Announcement      | [66](66.md)                            |
@@ -218,7 +218,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `11111`       | Transport Method Announcement   | [Nostr Epoxy][nostr-epoxy]             |
 | `13194`       | Wallet Info                     | [47](47.md)                            |
 | `13534`       | Membership Lists                | [43](43.md)                            |
-| `14388`       | User Sound Effect Lists         | [Corny Chat][cornychat-usersoundlist]  |
 | `17375`       | Cashu Wallet Event              | [60](60.md)                            |
 | `21000`       | Lightning Pub RPC               | [Lightning.Pub][lnpub]                 |
 | `22242`       | Client Authentication           | [42](42.md)                            |
@@ -274,9 +273,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `31989`       | Handler recommendation          | [89](89.md)                            |
 | `31990`       | Handler information             | [89](89.md)                            |
 | `32267`       | Software Application            |                                        |
-| `32388`       | User Room Favorites             | [Corny Chat][cornychat-roomfavorites]  |
-| `33388`       | High Scores                     | [Corny Chat][cornychat-highscores]     |
-| `34388`       | Sound Effects                   | [Corny Chat][cornychat-soundeffects]   |
 | `34550`       | Community Definition            | [72](72.md)                            |
 | `38172`       | Cashu Mint Announcement         | [87](87.md)                            |
 | `38173`       | Fedimint Announcement           | [87](87.md)                            |
@@ -290,12 +286,8 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 [NUD: Custom Feeds]: https://wikifreedia.xyz/cip-01/
 [nostrocket]: https://github.com/nostrocket/NIPS/blob/main/Problems.md
 [lnpub]: https://github.com/shocknet/Lightning.Pub/blob/master/proto/autogenerated/client.md
-[cornychat-usersoundlist]: https://cornychat.com/datatypes#kind14388usersoundeffectslist
 [cornychat-slideset]: https://cornychat.com/datatypes#kind30388slideset
 [cornychat-linkset]: https://cornychat.com/datatypes#kind31388linkset
-[cornychat-roomfavorites]: https://cornychat.com/datatypes#kind32388roomfavorites
-[cornychat-highscores]: https://cornychat.com/datatypes#kind33388highscores
-[cornychat-soundeffects]: https://cornychat.com/datatypes#kind34388soundeffectsets
 [joinstr]: https://gitlab.com/1440000bytes/joinstr/-/blob/main/NIP.md
 [NKBIP-01]: https://wikistr.com/nkbip-01*fd208ee8c8f283780a9552896e4823cc9dc6bfd442063889577106940fd927c1
 [NKBIP-02]: https://wikistr.com/nkbip-02*fd208ee8c8f283780a9552896e4823cc9dc6bfd442063889577106940fd927c1
@@ -304,8 +296,6 @@ 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
 
@@ -398,7 +388,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `repo`            | Reference to the origin repository   | --                              | [C0](C0.md)                                        |
 | `runtime`         | Runtime or environment specification | --                              | [C0](C0.md)                                        |
 | `server`          | file storage server url              | --                              | [96](96.md)                                        |
-| `sound`           | shortcode, sound url, image url      | --                              | [51](51.md)                                        |
 | `subject`         | subject                              | --                              | [14](14.md), [17](17.md), [34](34.md)              |
 | `summary`         | summary                              | --                              | [23](23.md), [52](52.md)                           |
 | `thumb`           | badge thumbnail                      | dimensions in pixels            | [58](58.md)                                        |