add custom field.

01.md

@@ -4,7 +4,7 @@ NIP-01
 Basic protocol flow description
 -------------------------------
 
-`draft` `mandatory` `relay`
+`draft` `mandatory`
 
 This NIP defines the basic protocol that should be implemented by everybody. New NIPs may add new optional (or mandatory) fields and messages and features to the structures and flows described here.
 

04.md

@@ -6,7 +6,7 @@ NIP-04
 Encrypted Direct Message
 ------------------------
 
-`final` `unrecommended` `optional` `relay`
+`final` `unrecommended` `optional`
 
 A special event with kind `4`, meaning "encrypted direct message". It is supposed to have the following attributes:
 

09.md

@@ -4,7 +4,7 @@ NIP-09
 Event Deletion Request
 ----------------------
 
-`draft` `optional` `relay`
+`draft` `optional`
 
 A special event with kind `5`, meaning "deletion request" is defined as having a list of one or more `e` or `a` tags, each referencing an event the author is requesting to be deleted. Deletion requests SHOULD include a `k` tag for the kind of each event being requested for deletion.
 

11.md

@@ -4,7 +4,7 @@ NIP-11
 Relay Information Document
 --------------------------
 
-`draft` `optional` `relay`
+`draft` `optional`
 
 Relays may provide server metadata to clients to inform them of capabilities, administrative contacts, and various server attributes.  This is made available as a JSON document over HTTP, on the same URI as the relay's websocket.
 

13.md

@@ -4,7 +4,7 @@ NIP-13
 Proof of Work
 -------------
 
-`draft` `optional` `relay`
+`draft` `optional`
 
 This NIP defines a way to generate and interpret Proof of Work for nostr notes. Proof of Work (PoW) is a way to add a proof of computational work to a note. This is a bearer proof that all relays and clients can universally validate with a small amount of code. This proof can be used as a means of spam deterrence.
 

17.md

@@ -4,7 +4,7 @@ NIP-17
 Private Direct Messages
 -----------------------
 
-`draft` `optional` `relay`
+`draft` `optional`
 
 This NIP defines an encrypted chat scheme which uses [NIP-44](44.md) encryption and [NIP-59](59.md) seals and gift wraps.
 

26.md

@@ -6,7 +6,7 @@ NIP-26
 Delegated Event Signing
 -----------------------
 
-`draft` `optional` `relay`
+`draft` `optional`
 
 This NIP defines how events can be delegated so that they can be signed by other keypairs.
 

29.md

@@ -4,7 +4,7 @@ NIP-29
 Relay-based Groups
 ------------------
 
-`draft` `optional` `relay`
+`draft` `optional`
 
 This NIP defines a standard for groups that are only writable by a closed set of users. They can be public for reading by external users or not.
 
@@ -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"],
-    ["closed"]
+    ["public"], // or ["private"]
+    ["open"] // or ["closed"]
   ]
   // other fields...
 }
 ```
 
-- `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.
+`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.
 
 - *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
 

40.md

@@ -4,7 +4,7 @@ NIP-40
 Expiration Timestamp
 --------------------
 
-`draft` `optional` `relay`
+`draft` `optional`
 
 The `expiration` tag enables users to specify a unix timestamp at which the message SHOULD be considered expired (by relays and clients) and SHOULD be deleted by relays.
 

42.md

@@ -4,7 +4,7 @@ NIP-42
 Authentication of clients to relays
 -----------------------------------
 
-`draft` `optional` `relay`
+`draft` `optional`
 
 This NIP defines a way for clients to authenticate to relays by signing an ephemeral event.
 

43.md

@@ -4,7 +4,7 @@ NIP-43
 Relay Access Metadata and Requests
 ----------------------------------
 
-`draft` `optional` `relay`
+`draft` `optional`
 
 This NIP defines a way for relays to advertise membership lists, and for clients to request admission to relays on behalf of users.
 

45.md

@@ -4,7 +4,7 @@ NIP-45
 Event Counts
 ------------
 
-`draft` `optional` `relay`
+`draft` `optional`
 
 Relays may support the verb `COUNT`, which provides a mechanism for obtaining event counts.
 

46.md

@@ -41,7 +41,7 @@ There are two ways to initiate a connection:
 
 _remote-signer_ provides connection token in the form:
 
- `relay`
+```
 bunker://<remote-signer-pubkey>?relay=<wss://relay-to-connect-on>&relay=<wss://another-relay-to-connect-on>&secret=<optional-secret-value>
 ```
 

50.md

@@ -4,7 +4,7 @@ NIP-50
 Search Capability
 -----------------
 
-`draft` `optional` `relay`
+`draft` `optional`
 
 ## Abstract
 

51.md

@@ -55,7 +55,6 @@ Aside from their main identifier, the `"d"` tag, sets can optionally have a `"ti
 | Bookmark sets         | 30003 | user-defined bookmarks categories , for when bookmarks must be in labeled separate groups    | `"e"` (kind:1 notes), `"a"` (kind:30023 articles)                                   |
 | Curation sets         | 30004 | groups of articles picked by users as interesting and/or belonging to the same category      | `"a"` (kind:30023 articles), `"e"` (kind:1 notes)                                   |
 | Curation sets         | 30005 | groups of videos picked by users as interesting and/or belonging to the same category        | `"e"` (kind:21 videos)                                                              |
-| Curation sets         | 30006 | groups of pictures picked by users as interesting and/or belonging to the same category      | `"e"` (kind:20 pictures)                                                            |
 | Kind mute sets        | 30007 | mute pubkeys by kinds<br>`"d"` tag MUST be the kind string                                   | `"p"` (pubkeys)                                                                     |
 | Interest sets         | 30015 | interest topics represented by a bunch of "hashtags"                                         | `"t"` (hashtags)                                                                    |
 | Emoji sets            | 30030 | categorized emoji groups                                                                     | `"emoji"` (see [NIP-30](30.md))                                                     |

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:
 

59.md

@@ -4,7 +4,7 @@ NIP-59
 Gift Wrap
 ---------
 
-`optional` `relay`
+`optional`
 
 This NIP defines a protocol for encapsulating any nostr event. This makes it possible to obscure most metadata
 for a given event, perform collaborative signing, and more.

62.md

@@ -4,7 +4,7 @@ NIP-62
 Request to Vanish
 -----------------
 
-`draft` `optional` `relay`
+`draft` `optional`
 
 This NIP offers a Nostr-native way to request a complete reset of a key's fingerprint on the web. This procedure is legally binding in some jurisdictions, and thus, supporters of this NIP should truly delete events from their database. 
 

66.md

@@ -4,7 +4,7 @@ NIP-66
 Relay Discovery and Liveness Monitoring
 -------------------
 
-`draft` `optional` `relay`
+`draft` `optional`
 
 This NIP defines events for relay discovery and the announcement of relay monitors.
 

70.md

@@ -4,7 +4,7 @@ NIP-70
 Protected Events
 ----------------
 
-`draft` `optional` `relay`
+`draft` `optional`
 
 When the `"-"` tag is present, that means the event is "protected".
 

77.md

@@ -4,7 +4,7 @@ NIP-77
 Negentropy Syncing
 ------------------
 
-`draft` `optional` `relay`
+`draft` `optional`
 
 This document describes a protocol extension for syncing events. It works for both client-relay and relay-relay scenarios. If both sides of the sync have events in common, then this protocol will use less bandwidth than transferring the full set of events (or even just their IDs).
 

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
+}
+```

README.md

@@ -103,7 +103,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-98: HTTP Auth](98.md)
 - [NIP-99: Classified Listings](99.md)
 - [NIP-A0: Voice Messages](A0.md)
-- [NIP-A4: Public Messages](A4.md)
 - [NIP-B0: Web Bookmarks](B0.md)
 - [NIP-B7: Blossom](B7.md)
 - [NIP-BE: Nostr BLE Communications Protocol](BE.md)
@@ -135,7 +134,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `20`          | Picture                         | [68](68.md)                            |
 | `21`          | Video Event                     | [71](71.md)                            |
 | `22`          | Short-form Portrait Video Event | [71](71.md)                            |
-| `24`          | Public Message                  | [A4](A4.md)                            |
 | `30`          | internal reference              | [NKBIP-03]                             |
 | `31`          | external web reference          | [NKBIP-03]                             |
 | `32`          | hardcopy reference              | [NKBIP-03]                             |
@@ -238,7 +236,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `30003`       | Bookmark sets                   | [51](51.md)                            |
 | `30004`       | Curation sets                   | [51](51.md)                            |
 | `30005`       | Video sets                      | [51](51.md)                            |
-| `30006`       | Picture sets                    | [51](51.md)                            |
 | `30007`       | Kind mute sets                  | [51](51.md)                            |
 | `30008`       | Profile Badges                  | [58](58.md)                            |
 | `30009`       | Badge Definition                | [58](58.md)                            |