add nipB0, social bookmarking.

22.md

@@ -18,9 +18,9 @@ and `p` for the author of the parent item.
 
 ```jsonc
 {
-  "kind": 1111,
+  kind: 1111,
-  "content": "<comment>",
+  content: '<comment>',
-  "tags": [
+  tags: [
     // root scope: event addresses, event ids, or I-tags.
     ["<A, E, I>", "<address, id or I-value>", "<relay or web page hint>", "<root event's pubkey, if an E tag>"],
     // the root item kind
@@ -64,9 +64,9 @@ A comment on a blog post looks like this:
 
 ```jsonc
 {
-  "kind": 1111,
+  kind: 1111,
-  "content": "Great blog post!",
+  content: 'Great blog post!',
-  "tags": [
+  tags: [
     // top-level comments scope to event addresses or ids
     ["A", "30023:3c9849383bdea883b0bd16fece1ed36d37e37cdde3ce43b17ea4e9192ec11289:f9347ca7", "wss://example.relay"],
     // the root kind
@@ -91,9 +91,9 @@ A comment on a [NIP-94](94.md) file looks like this:
 
 ```jsonc
 {
-  "kind": 1111,
+  kind: 1111,
-  "content": "Great file!",
+  content: 'Great file!',
-  "tags": [
+  tags: [
     // top-level comments have the same scope and reply to addresses or ids
     ["E", "768ac8720cdeb59227cf95e98b66560ef03d8bc9a90d721779e76e68fb42f5e6", "wss://example.relay", "3721e07b079525289877c366ccab47112bdff3d1b44758ca333feb2dbbbbe5bb"],
     // the root kind
@@ -115,9 +115,9 @@ A reply to a comment looks like this:
 
 ```jsonc
 {
-  "kind": 1111,
+  kind: 1111,
-  "content": "This is a reply to \"Great file!\"",
+  content: 'This is a reply to "Great file!"',
-  "tags": [
+  tags: [
     // nip-94 file event id
     ["E", "768ac8720cdeb59227cf95e98b66560ef03d8bc9a90d721779e76e68fb42f5e6", "wss://example.relay", "fd913cd6fa9edb8405750cd02a8bbe16e158b8676c0e69fdc27436cc4a54cc9a"],
     // the root kind
@@ -138,9 +138,9 @@ A comment on a website's url looks like this:
 
 ```jsonc
 {
-  "kind": 1111,
+  kind: 1111,
-  "content": "Nice article!",
+  content: 'Nice article!',
-  "tags": [
+  tags: [
     // referencing the root url
     ["I", "https://abc.com/articles/1"],
     // the root "kind": for an url, the kind is its domain
@@ -159,11 +159,11 @@ A podcast comment example:
 
 ```jsonc
 {
-  "id": "80c48d992a38f9c445b943a9c9f1010b396676013443765750431a9004bdac05",
+  id: "80c48d992a38f9c445b943a9c9f1010b396676013443765750431a9004bdac05",
-  "pubkey": "252f10c83610ebca1a059c0bae8255eba2f95be4d1d7bcfa89d7248a82d9f111",
+  pubkey: "252f10c83610ebca1a059c0bae8255eba2f95be4d1d7bcfa89d7248a82d9f111",
-  "kind": 1111,
+  kind: 1111,
-  "content": "This was a great episode!",
+  content: "This was a great episode!",
-  "tags": [
+  tags: [
     // podcast episode reference
     ["I", "podcast:item:guid:d98d189b-dc7b-45b1-8720-d4b98690f31f", "https://fountain.fm/episode/z1y9TMQRuqXl2awyrQxg"],
     // podcast episode type
@@ -181,9 +181,9 @@ A reply to a podcast comment:
 
 ```jsonc
 {
-  "kind": 1111,
+  kind: 1111,
-  "content": "I'm replying to the above comment.",
+  content: "I'm replying to the above comment.",
-  "tags": [
+  tags: [
     // podcast episode reference
     ["I", "podcast:item:guid:d98d189b-dc7b-45b1-8720-d4b98690f31f", "https://fountain.fm/episode/z1y9TMQRuqXl2awyrQxg"],
     // podcast episode type

26.md

@@ -1,5 +1,3 @@
-> __Warning__  `unrecommended`: adds unecessary burden for little gain
-
 NIP-26
 =======
 

60.md

@@ -68,7 +68,7 @@ There can be multiple `kind:7375` events for the same mint, and multiple proofs
 
  * `.content` is a [NIP-44](44.md) encrypted payload:
    * `mint`: The mint the proofs belong to.
-   * `proofs`: unencoded proofs
+   * `proofs`: unecoded proofs
    * `del`: token-ids that were destroyed by the creation of this token. This assists with state transitions.
 
 When one or more proofs of a token are spent, the token event should be [NIP-09](09.md)-deleted and, if some proofs are unspent from the same token event, a new token event should be created rolling over the unspent proofs and adding any change outputs to the new token event (the change output should include a `del` field).

61.md

@@ -46,10 +46,10 @@ Clients MUST prefix the public key they P2PK-lock with `"02"` (for nostr<>cashu
 
 ```jsonc
 {
-    "kind": 9321,
+    kind: 9321,
-    "content": "Thanks for this great idea.",
+    content: "Thanks for this great idea.",
-    "pubkey": "<sender-pubkey>",
+    pubkey: "<sender-pubkey>",
-    "tags": [
+    tags: [
         [ "proof", "{\"amount\":1,\"C\":\"02277c66191736eb72fce9d975d08e3191f8f96afb73ab1eec37e4465683066d3f\",\"id\":\"000a93d6f8a1d2c4\",\"secret\":\"[\\\"P2PK\\\",{\\\"nonce\\\":\\\"b00bdd0467b0090a25bdf2d2f0d45ac4e355c482c1418350f273a04fedaaee83\\\",\\\"data\\\":\\\"02eaee8939e3565e48cc62967e2fde9d8e2a4b3ec0081f29eceff5c64ef10ac1ed\\\"}]\"}" ],
         [ "u", "https://stablenut.umint.cash" ],
         [ "e", "<nutzapped-event-id>", "<relay-hint>" ],

65.md

@@ -32,7 +32,6 @@ When publishing an event, clients SHOULD:
 
 - Send the event to the **write** relays of the author
 - Send the event to all **read** relays of each tagged user
-- Send the author's `kind:10002` event to all relays the event was published to
 
 ### Size
 

66.md

@@ -1,8 +1,4 @@
-NIP-66
+# NIP-66: Relay Discovery and Liveness Monitoring
-======
-
-Relay Discovery and Liveness Monitoring
--------------------
 
 `draft` `optional`
 

69.md

@@ -1,8 +1,6 @@
-NIP-69
+# NIP-69
-======
 
-Peer-to-peer Order events
+## Peer-to-peer Order events
--------------------------
 
 `draft` `optional`
 

88.md

@@ -1,8 +1,6 @@
-NIP-88
+# NIP-88
-======
 
-Polls
+## Polls
------
 
 `draft` `optional`
 

90.md

@@ -1,44 +1,230 @@
 NIP-90
 ======
 
-Data Vending Machines
+Data Vending Machine
----------------------
+--------------------
 
 `draft` `optional`
 
-This NIP is a documentation effort and a hub for incentivizing the proliferation of DVMs on Nostr.
+This NIP defines the interaction between customers and Service Providers for performing on-demand computation.
 
-A DVM is anything that can be interacted with programmatically, either to benefit Nostr clients in general or making use of the Nostr ecosystem.
+Money in, data out.
 
-There are 3 types of DVM-related interaction:
+## Kinds
+This NIP reserves the range `5000-7000` for data vending machine use.
 
-- A "bot", i.e. a Nostr profile, optionally with a `kind:0` metadata, that may or may not publish `kind:1`s with human-readable notes, that can be controlled by a human or by a computer program.
+| Kind      | Description       |
-- A "service", i.e., a server exposing a HTTP/JSON API (although other formats aren't out of scope either).
+| ----      | -----------       |
-- A "relay", i.e. a server exposing a [NIP-01](01.md) WebSocket endpoint.
+| 5000-5999 | Job request kinds |
+| 6000-6999 | Job result        |
+| 7000      | Job feedback      |
 
-To qualify as a DVM entity a thing must:
+Job results always use a kind number that is `1000` higher than the job request kind. (e.g. request: `kind:5001` gets a result: `kind:6001`).
 
-- Accept inputs in some way, such as: by reading some specific event kind from one or more relays; by accept HTTP requests to its own HTTP API; or by receiving `EVENT` or `REQ` messages in its own WebSocket endpoint.
+Job request types are defined [separately](https://github.com/nostr-protocol/data-vending-machines/tree/master/kinds).
-- Produce outputs in some way, such as: by publishing some kind of event to one or more relays; by returning an HTTP response; or by returning `EVENT`s in its WebSocket connection.
 
-It's important to notice that such definition of DVM encompasses basically everything in the world -- including Nostr relays, Nostr clients and Nostr users (yes, we are all DVMs), but this NIP limits itself to describing standards that emerge naturally for interaction flows that:
+## Rationale
+Nostr can act as a marketplace for data processing, where users request jobs to be processed in certain ways (e.g., "speech-to-text", "summarization", etc.), but they don't necessarily care about "who" processes the data.
 
-- Will benefit from standardization such that more than one DVM can exist fulfilling the same role and more than one client or consumer can exist that interacts with such DVM directly;
+This NIP is not to be confused with a 1:1 marketplace; instead, it describes a flow where a user announces a desired output, willingness to pay, and service providers compete to fulfill the job requirement in the best way possible.
-- Aren't defined anywhere else and that would be difficult to define in other NIPs.
 
-### DVMs
+### Actors
+There are two actors in the workflow described in this NIP:
+* Customers (npubs who request a job)
+* Service providers (npubs who fulfill jobs)
 
-#### Translation
+## Job request (`kind:5000-5999`)
+A request to process data, published by a customer. This event signals that a customer is interested in receiving the result of some kind of compute.
 
-- TODO: nostr.wine HTTP translation
+```jsonc
-- TODO: event-based translation?
+{
+    "kind": 5xxx, // kind in 5000-5999 range
+    "content": "",
+    "tags": [
+        [ "i", "<data>", "<input-type>", "<relay>", "<marker>" ],
+        [ "output", "<mime-type>" ],
+        [ "relays", "wss://..." ],
+        [ "bid", "<msat-amount>" ],
+        [ "t", "bitcoin" ]
+    ],
+    // other fields...
+}
+```
 
-#### Trending feeds
+All tags are optional.
 
-- TODO: primal HTTP trending feeds
+* `i` tag: Input data for the job (zero or more inputs)
-- TODO: nostr.band HTTP trending feeds
+    * `<data>`: The argument for the input
-- TODO: DVM-based trending feeds
+    * `<input-type>`: The way this argument should be interpreted. MUST be one of:
+        * `url`: A URL to be fetched of the data that should be processed.
+        * `event`: A Nostr event ID.
+        * `job`: The output of a previous job with the specified event ID. The dermination of which output to build upon is up to the service provider to decide (e.g. waiting for a signaling from the customer, waiting for a payment, etc.)
+        * `text`: `<data>` is the value of the input, no resolution is needed
+    * `<relay>`: If `event` or `job` input-type, the relay where the event/job was published, otherwise optional or empty string
+    * `<marker>`: An optional field indicating how this input should be used within the context of the job
+* `output`: Expected output format. Different job request `kind` defines this more precisely.
+* `param`: Optional parameters for the job as key (first argument)/value (second argument). Different job request `kind` defines this more precisely. (e.g. `[ "param", "lang", "es" ]`)
+* `bid`: Customer MAY specify a maximum amount (in millisats) they are willing to pay
+* `relays`: List of relays where Service Providers SHOULD publish responses to
+* `p`: Service Providers the customer is interested in. Other SPs MIGHT still choose to process the job
 
-#### Whatever
+## Encrypted Params
 
-- TODO:
+If the user wants to keep the input parameters a secret, they can encrypt the `i` and `param` tags with the service provider's 'p' tag and add it to the content field. Add a tag `encrypted` as tags. Encryption for private tags will use [NIP-04 - Encrypted Direct Message encryption](04.md), using the user's private and service provider's public key for the shared secret
+
+```json
+[
+  ["i", "what is the capital of France? ", "text"],
+  ["param", "model", "LLaMA-2"],
+  ["param", "max_tokens", "512"],
+  ["param", "temperature", "0.5"],
+  ["param", "top-k", "50"],
+  ["param", "top-p", "0.7"],
+  ["param", "frequency_penalty", "1"]
+]
+```
+
+This param data will be encrypted and added to the `content` field and `p` tag should be present
+
+```jsonc
+{
+  "content": "BE2Y4xvS6HIY7TozIgbEl3sAHkdZoXyLRRkZv4fLPh3R7LtviLKAJM5qpkC7D6VtMbgIt4iNcMpLtpo...",
+  "tags": [
+    ["p", "04f74530a6ede6b24731b976b8e78fb449ea61f40ff10e3d869a3030c4edc91f"],
+    ["encrypted"]
+  ],
+  // other fields...
+}
+```
+
+
+## Job result (`kind:6000-6999`)
+
+Service providers publish job results, providing the output of the job result. They should tag the original job request event id as well as the customer's pubkey.
+
+```jsonc
+{
+  "pubkey": "<service-provider pubkey>",
+  "content": "<payload>",
+  "kind": 6xxx,
+  "tags": [
+    ["request", "<job-request>"],
+    ["e", "<job-request-id>", "<relay-hint>"],
+    ["i", "<input-data>"],
+    ["p", "<customer's-pubkey>"],
+    ["amount", "requested-payment-amount", "<optional-bolt11>"]
+  ],
+  // other fields...
+}
+```
+
+* `request`: The job request event stringified-JSON.
+* `amount`: millisats that the Service Provider is requesting to be paid. An optional third value can be a bolt11 invoice.
+* `i`: The original input(s) specified in the request.
+
+## Encrypted Output
+
+If the request has encrypted params, then output should be encrypted and placed in  `content` field. If the output is encrypted, then avoid including `i` tag with input-data as clear text.
+Add a tag encrypted to mark the output content as `encrypted`
+
+```jsonc
+{
+  "pubkey": "<service-provider pubkey>",
+  "content": "<encrypted payload>",
+  "kind": 6xxx,
+  "tags": [
+    ["request", "<job-request>"],
+    ["e", "<job-request-id>", "<relay-hint>"],
+    ["p", "<customer's-pubkey>"],
+    ["amount", "requested-payment-amount", "<optional-bolt11>"],
+    ["encrypted"]
+  ],
+  // other fields...
+}
+```
+
+## Job feedback
+
+Service providers can give feedback about a job back to the customer.
+
+```jsonc
+{
+  "kind": 7000,
+  "content": "<empty-or-payload>",
+  "tags": [
+    ["status", "<status>", "<extra-info>"],
+    ["amount", "requested-payment-amount", "<bolt11>"],
+    ["e", "<job-request-id>", "<relay-hint>"],
+    ["p", "<customer's-pubkey>"],
+  ],
+  // other fields...
+}
+```
+
+* `content`: Either empty or a job-result (e.g. for partial-result samples)
+* `amount` tag: as defined in the [Job Result](#job-result-kind6000-6999) section.
+* `status` tag: Service Providers SHOULD indicate what this feedback status refers to. [Job Feedback Status](#job-feedback-status) defines status. Extra human-readable information can be added as an extra argument.
+
+* NOTE: If the input params requires input to be encrypted, then `content` field will have encrypted payload with `p` tag as key.
+
+### Job feedback status
+
+| status             | description                                                                                                 |
+| --------           | -------------                                                                                               |
+| `payment-required` | Service Provider requires payment before continuing.                                                        |
+| `processing`       | Service Provider is processing the job.                                                                     |
+| `error`            | Service Provider was unable to process the job.                                                             |
+| `success`          | Service Provider successfully processed the job.                                                            |
+| `partial`          | Service Provider partially processed the job. The `.content` might include a sample of the partial results. |
+
+Any job feedback event MIGHT include results in the `.content` field, as described in the [Job Result](#job-result-kind6000-6999) section. This is useful for service providers to provide a sample of the results that have been processed so far.
+
+
+# Protocol Flow
+
+* Customer publishes a job request (e.g. `kind:5000` speech-to-text).
+* Service Providers MAY submit `kind:7000` job-feedback events (e.g. `payment-required`, `processing`, `error`, etc.).
+* Upon completion, the service provider publishes the result of the job with a `kind:6000` job-result event.
+* At any point, if there is an `amount` pending to be paid as instructed by the service provider, the user can pay the included `bolt11` or zap the job result event the service provider has sent to the user.
+
+Job feedback (`kind:7000`) and Job Results (`kind:6000-6999`) events MAY include an `amount` tag, this can be interpreted as a suggestion to pay. Service Providers MUST use the `payment-required` feedback event to signal that a payment is required and no further actions will be performed until the payment is sent.
+
+Customers can always either pay the included `bolt11` invoice or zap the event requesting the payment and service providers should monitor for both if they choose to include a bolt11 invoice.
+
+## Notes about the protocol flow
+The flow is deliberately ambiguous, allowing vast flexibility for the interaction between customers and service providers so that service providers can model their behavior based on their own decisions/perceptions of risk.
+
+Some service providers might choose to submit a `payment-required` as the first reaction before sending a `processing` or before delivering results, some might choose to serve partial results for the job (e.g. a sample), send a `payment-required` to deliver the rest of the results, and some service providers might choose to assess likelihood of payment based on an npub's past behavior and thus serve the job results before requesting payment for the best possible UX.
+
+It's not up to this NIP to define how individual vending machines should choose to run their business.
+
+# Cancellation
+A job request might be canceled by publishing a `kind:5` delete request event tagging the job request event.
+
+# Appendix 1: Job chaining
+A Customer MAY request multiple jobs to be processed as a chain, where the output of a job is the input of another job. (e.g. podcast transcription -> summarization of the transcription). This is done by specifying as input an event id of a different job with the `job` type.
+
+Service Providers MAY begin processing a subsequent job the moment they see the prior job's result, but they will likely wait for a zap to be published first. This introduces a risk that Service Provider of job #1 might delay publishing the zap event in order to have an advantage. This risk is up to Service Providers to mitigate or to decide whether the service provider of job #1 tends to have good-enough results so as to not wait for an explicit zap to assume the job was accepted.
+
+This gives a higher level of flexibility to service providers (which sophisticated service providers would take anyway).
+
+# Appendix 2: Service provider discoverability
+Service Providers MAY use NIP-89 announcements to advertise their support for job kinds:
+
+```jsonc
+{
+  "kind": 31990,
+  "pubkey": "<pubkey>",
+  "content": "{
+    \"name\": \"Translating DVM\",
+    \"about\": \"I'm a DVM specialized in translating Bitcoin content.\"
+  }",
+  "tags": [
+    ["k", "5005"], // e.g. translation
+    ["t", "bitcoin"] // e.g. optionally advertises it specializes in bitcoin audio transcription that won't confuse "Drivechains" with "Ridechains"
+  ],
+  // other fields...
+}
+```
+
+Customers can use NIP-89 to see what service providers their follows use.

B0.md

@@ -1,61 +0,0 @@
-NIP-B0
-======
-
-Web Bookmarking
----------------
-
-`draft` `optional`
-
-This NIP defines `kind:39701` (an _addressable event_) for a URI as a web bookmark which uses the HTTP (Hypertext transfer protocol) scheme.
-These web bookmark events are _addressable_ and deletable per [NIP-09](09.md).
-
-### Editability
-
-Web bookmarks are meant to be editable, so they should include a `d` tag with an identifier for the bookmark. Clients should take care to only publish and read these events from relays that implement that. If they don't do that they should also take care to hide old versions of the same bookmark they may receive.
-
-### Format
-
-The format uses an _addressable event_ of `kind:39701`.
-
-The `.content` of these events should be a detailed description of the web bookmark. It is required but can be an empty string.
-
-The `d` tag is required.
-
-In this way web bookmarks events can be queried by the `d` tag by clients, which is just their URL without the scheme, which is always and everywhere assumed to be `https://` or `http://`.
-
-The querystring and the hash must be removed entirely, unless their requirement is explicitly stated either by the user or by some hardcoded list of URLs that rely on querystrings for basic routing provided by the client.
-
-### Metadata
-
-For the date of the last update the `.created_at` field should be used. For "tags"/"hashtags" (i.e. topics about which the event might be of relevance) the `t` tag should be used.
-
-Other metadata fields can be added as tags to the event as necessary.
-
-* `"published_at"`, for the timestamp in unix seconds (stringified) of the first time the bookmark was published
-* `"title"`, title about bookmark and can be used as a attribute for the HTML link element
-
-## Example event 
-
-```jsonc
-{
-  "kind": 39701,
-  "id": "d7a92714f81d0f712e715556aee69ea6da6bfb287e6baf794a095d301d603ec7",
-  "pubkey": "2729620da105979b22acfdfe9585274a78c282869b493abfa4120d3af2061298",
-  "created_at": 1738869705,
-  "tags": [
-    // Required tags
-    ["d", "alice.blog/post"],
-    // Optional tags    
-    ["published_at", "1738863000"],
-    ["title", "Blog insights by Alice"],  
-    ["t", "post"],
-    ["t", "insight"]
-  ],
-  "content": "A marvelous insight by Alice about the nature of blogs and posts.",
-  "sig": "36d34e6448fe0223e9999361c39c492a208bc423d2fcdfc2a3404e04df7c22dc65bbbd62dbe8a4373c62e4d29aac285b5aa4bb9b4b8053bd6207a8b45fbd0c98"
-}
-```
-
-### Replies & Comments
-
-Replies to `kind 39701` MUST use `kind 1111` events as comments with [NIP-22](22.md).

B7.md

@@ -1,41 +0,0 @@
-NIP-B7
-======
-
-Blossom media
--------------
-
-`draft` `optional`
-
-This NIP specifies how Nostr clients can use [Blossom][] for handling media.
-
-Blossom is a set of standards (called BUDs) for dealing with servers that store files addressable by their SHA-256 sums. Nostr clients may make use of all the BUDs for allowing users to upload files, manage their own files and so on, but most importantly Nostr clients SHOULD make use of [BUD-03][] to fetch `kind:10063` lists of servers for each user:
-
-```json
-{
-  "id": "e4bee088334cb5d38cff1616e964369c37b6081be997962ab289d6c671975d71",
-  "pubkey": "781208004e09102d7da3b7345e64fd193cd1bc3fce8fdae6008d77f9cabcd036",
-  "content": "",
-  "kind": 10063,
-  "created_at": 1708774162,
-  "tags": [
-    ["server", "https://blossom.self.hosted"],
-    ["server", "https://cdn.blossom.cloud"]
-  ],
-  "sig": "cc5efa74f59e80622c77cacf4dd62076bcb7581b45e9acff471e7963a1f4d8b3406adab5ee1ac9673487480e57d20e523428e60ffcc7e7a904ac882cfccfc653"
-}
-```
-
-Whenever a Nostr client finds a URL in an event published by a given user and that URL ends a 64-character hex string (with or without an ending file extension) and that URL is not available anymore, that means that string is likely a representation of a sha256 and that the user may have a `kind:10063` list of Blossom servers published.
-
-Given that, the client SHOULD look into the `kind:10063` list for other Blossom servers and lookup for the same 64-character hex string in them, by just using the hex string as a path (optionally with the file extension at the end), producing a URL like `https://blossom.self.hosted/<hex-string>.png`.
-
-When downloading such files Nostr clients SHOULD verify that the sha256-hash of its contents matches the 64-character hex string.
-
-More information can be found at [BUD-03][].
-
-### More complex interactions
-
-Clients may use other facilities exposed by Blossom servers (for example, for checking if a file exists in a Blossom server, instead of actually downloading it) which are better documented in the [BUDs][Blossom].
-
-[Blossom]: https://github.com/hzrd149/blossom
-[BUD-03]: https://github.com/hzrd149/blossom/blob/master/buds/03.md

C0.md

@@ -1,8 +1,4 @@
-NIP-C0
+# NIP-C0: Code Snippets
-======
-
-Code Snippets
--------------
 
 `draft` `optional`
 

README.md

@@ -44,7 +44,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-23: Long-form Content](23.md)
 - [NIP-24: Extra metadata fields and tags](24.md)
 - [NIP-25: Reactions](25.md)
-- [NIP-26: Delegated Event Signing](26.md) --- **unrecommended**: adds unecessary burden for little gain
+- [NIP-26: Delegated Event Signing](26.md)
 - [NIP-27: Text Note References](27.md)
 - [NIP-28: Public Chat](28.md)
 - [NIP-29: Relay-based Groups](29.md)
@@ -89,7 +89,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-73: External Content IDs](73.md)
 - [NIP-75: Zap Goals](75.md)
 - [NIP-78: Application-specific data](78.md)
-- [NIP-7D: Threads](7D.md)
 - [NIP-84: Highlights](84.md)
 - [NIP-86: Relay Management API](86.md)
 - [NIP-88: Polls](88.md)
@@ -100,8 +99,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-96: HTTP File Storage Integration](96.md)
 - [NIP-98: HTTP Auth](98.md)
 - [NIP-99: Classified Listings](99.md)
-- [NIP-B0: Web Bookmarks](B0.md)
+- [NIP-7D: Threads](7D.md)
-- [NIP-B7: Blossom](B7.md)
 - [NIP-C0: Code Snippets](C0.md)
 - [NIP-C7: Chats](C7.md)
 
@@ -165,6 +163,9 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `2004`        | Torrent Comment                 | [35](35.md)                            |
 | `2022`        | Coinjoin Pool                   | [joinstr][joinstr]                     |
 | `4550`        | Community Post Approval         | [72](72.md)                            |
+| `5000`-`5999` | Job Request                     | [90](90.md)                            |
+| `6000`-`6999` | Job Result                      | [90](90.md)                            |
+| `7000`        | Job Feedback                    | [90](90.md)                            |
 | `7374`        | Reserved Cashu Wallet Tokens    | [60](60.md)                            |
 | `7375`        | Cashu Wallet Tokens             | [60](60.md)                            |
 | `7376`        | Cashu Wallet History            | [60](60.md)                            |
@@ -246,7 +247,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `34550`       | Community Definition            | [72](72.md)                            |
 | `38383`       | Peer-to-peer Order events       | [69](69.md)                            |
 | `39000-9`     | Group metadata events           | [29](29.md)                            |
-| `39701`       | Web bookmarks                   | [B0](B0.md)                            |
 
 [NUD: Custom Feeds]: https://wikifreedia.xyz/cip-01/
 [nostrocket]: https://github.com/nostrocket/NIPS/blob/main/Problems.md
@@ -326,6 +326,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `dep`             | Required dependency                  | --                              | [C0](C0.md)                                        |
 | `description`     | description                          | --                              | [34](34.md), [57](57.md), [58](58.md), [C0](C0.md) |
 | `emoji`           | shortcode, image URL                 | --                              | [30](30.md)                                        |
+| `encrypted`       | --                                   | --                              | [90](90.md)                                        |
 | `extension`       | File extension                       | --                              | [C0](C0.md)                                        |
 | `expiration`      | unix timestamp (string)              | --                              | [40](40.md)                                        |
 | `file`            | full path (string)                   | --                              | [35](35.md)                                        |
@@ -340,7 +341,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `preimage`        | hash of `bolt11` invoice             | --                              | [57](57.md)                                        |
 | `price`           | price                                | currency, frequency             | [99](99.md)                                        |
 | `proxy`           | external ID                          | protocol                        | [48](48.md)                                        |
-| `published_at`    | unix timestamp (string)              | --                              | [23](23.md), [B0](B0.md)                           |
+| `published_at`    | unix timestamp (string)              | --                              | [23](23.md)                                        |
 | `relay`           | relay url                            | --                              | [42](42.md), [17](17.md)                           |
 | `relays`          | relay list                           | --                              | [57](57.md)                                        |
 | `repo`            | Reference to the origin repository   | --                              | [C0](C0.md)                                        |
@@ -349,7 +350,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `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)                                        |
-| `title`           | title                                | --                              | [23](23.md), [B0](B0.md)                           |
+| `title`           | article title                        | --                              | [23](23.md)                                        |
 | `tracker`         | torrent tracker URL                  | --                              | [35](35.md)                                        |
 | `web`             | webpage URL                          | --                              | [34](34.md)                                        |
 | `zap`             | pubkey (hex), relay URL              | weight                          | [57](57.md)                                        |

b0.md

@@ -0,0 +1,31 @@
+NIP-B0
+======
+
+Web Bookmarking
+---------------
+
+`draft` `optional`
+
+This NIP defines `kind:39701` as website bookmarks.
+
+```jsonc
+{
+  "kind": 39701,
+  "id": "d7a92714f81d0f712e715556aee69ea6da6bfb287e6baf794a095d301d603ec7",
+  "pubkey": "2729620da105979b22acfdfe9585274a78c282869b493abfa4120d3af2061298",
+  "created_at": 1738869705,
+  "tags": [
+    ["d", "alice.blog/post"],
+    ["t", "post"],
+    ["t", "insight"]
+  ],
+  "content": "A marvelous insight by Alice about the nature of blogs and posts.",
+  "sig": "36d34e6448fe0223e9999361c39c492a208bc423d2fcdfc2a3404e04df7c22dc65bbbd62dbe8a4373c62e4d29aac285b5aa4bb9b4b8053bd6207a8b45fbd0c98"
+}
+```
+
+Bookmarks can be queried by the `d` tag, which is just their URL without the scheme, which is always and everywhere assumed to be `https://`.
+
+The querystring and the hash must be removed entirely, unless their requirement is explicitly stated either by the user or by some hardcoded list of URLs that rely on querystrings for basic routing provided by the client (I've searched the internet extensively and could only find 3 websites that do this: YouTube, Hacker News and a random guy's sad old blog).
+
+Bookmarks can be commented on with [NIP-22](22.md).