add custom field.

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
 

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:
 

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.

F1.md

@@ -0,0 +1,38 @@
+NIP-F1
+======
+
+Profile Hypercustomization
+--------------------------
+
+`draft` `optional`
+
+This NIP describes a new event `kind:19999` that can be used for multiple optional and weird forms of profile customization, such as extra colors, extra pictures, preferences and background music.
+
+It's completely optional and clients may choose to fulfill only some of these tags, or none. Clients may also allow users to turn off these customizations or not.
+
+## Tags
+
+| Name               | Value type                         | Description                                                                             |
+| ---                | ----                               | -----------                                                                             |
+| `background-color` | hex value                          | To be used by clients when displaying the user profile page                             |
+| `foreground-color` | hex value                          | Idem                                                                                    |
+| `background-music` | URL                                | Music that optionally plays when the profile is opened                                  |
+| `priority_kinds`   | stringified kind number (variadic) | Kinds to be displayed by default in the user profile page (rather than `kind:1` always) |
+| `custom`           | string name, then value            | An arbitrary field to be displayed along with the profile                               |
+
+## Example
+
+```yaml
+{
+  "kind": 19999,
+  "tags": [
+    ["background-color", "#1a1a2e"],
+    ["foreground-color", "#eee444"],
+    ["background-music", "https://example.com/music/profile-theme.mp3"],
+    ["priority_kinds", "20", "30023", "21", "10009"],
+    ["custom", "favorite fruit", "banana"],
+    ["custom", "pets?", "no"]
+  ],
+  // ...other fields
+}
+```