Clarify closed/private, add hidden to nip 29 (#2106)

Co-authored-by: Jon Staab <shtaab@gmail.com>

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 acceptances in `closed` groups, together with the `kind:9009` `create-invite` moderation event.
+The optional `code` tag may be used by the relay to preauthorize acceptance, together with the `kind:9009` `create-invite` moderation event.
 
 - *leave request* (`kind:9022`)
 
@@ -153,14 +153,18 @@ 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"],
-    ["public"], // or ["private"]
+    ["private"],
-    ["open"] // or ["closed"]
+    ["closed"]
   ]
   // other fields...
 }
 ```
 
-`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.
+- `name`, `picture` and `about` are basic metadata for the group for display purposes.
+- `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)
 
@@ -231,7 +235,7 @@ The latest of either `kind:9000` or `kind:9001` events present in a group should
 
 ### Adding yourself to a group
 
-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.
+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.
 
 ### Storing your list of groups
 

55.md

@@ -107,6 +107,13 @@ 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**
@@ -299,33 +306,6 @@ 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:
 

A4.md

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