diff --git a/src/key_management.md b/src/key_management.md index 5fb5748..d902da1 100644 --- a/src/key_management.md +++ b/src/key_management.md @@ -166,7 +166,7 @@ Clients must offer a more private version where the client never send the identi ## Protocol v2 — NIP-44 direct messages Everything above describes **protocol v1** (NIP-59 gift wrap, kind `1059`), -which is **DEPRECATED**. Nodes that advertise `protocol_versions = "2"` in +which is **DEPRECATED**. Nodes that advertise `protocol_version = "2"` in their [instance-info event](./other_events.md#mostro-instance-status) speak **protocol v2** instead: a single signed [NIP-44](https://github.com/nostr-protocol/nips/blob/master/44.md) direct message of kind `14`, with no gift-wrap or seal layer. The key @@ -187,8 +187,9 @@ What changes on the wire: - **The array gains a third element**, the identity proof — because there is no seal to carry the identity key authenticated. See below. - **An `expiration` tag** ([NIP-40](https://github.com/nostr-protocol/nips/blob/master/40.md)) - is always present so trade messages do not linger on relays forever - (default 30 days, the node's `dm_days` setting). + is always present so trade messages do not linger on relays forever. The + concrete expiration window is chosen by the node and is not part of the + protocol. - **`version` is `2`** in the message. > **Note (deliberate NIP-17 deviation):** [NIP-17](https://github.com/nostr-protocol/nips/blob/master/17.md) diff --git a/src/other_events.md b/src/other_events.md index 0d0da4d..5f33bf9 100644 --- a/src/other_events.md +++ b/src/other_events.md @@ -118,7 +118,7 @@ This event contains specific data about a Mostro instance. The instance is ident "0" ], [ - "protocol_versions", + "protocol_version", "1" ], [ @@ -218,7 +218,7 @@ Below is an explanation of the meaning of some of the labels in this event, all - `max_orders_per_response`: Maximum complete orders data per response in orders action. - `fee`: The fee percentage charged by the instance. For example, "0.006" means a 0.6% fee. - `pow`: The Proof of Work required of incoming events. -- `protocol_versions`: The Mostro protocol (wire transport) this node speaks — `"1"` for NIP-59 gift wrap (kind `1059`, DEPRECATED) or `"2"` for NIP-44 direct messages (kind `14`). A node speaks exactly one; clients read this tag to pick the matching wire format. See the [client migration guide](./transport_migration.md). +- `protocol_version`: The Mostro protocol (wire transport) this node speaks — `"1"` for NIP-59 gift wrap (kind `1059`, DEPRECATED) or `"2"` for NIP-44 direct messages (kind `14`). A node speaks exactly one; clients read this tag to pick the matching wire format. See the [client migration guide](./transport_migration.md). - `hold_invoice_expiration_window`: The maximum time, in seconds, for the hold invoice issued by Mostro to be paid by the seller. - `hold_invoice_cltv_delta`: The number of blocks in which the Mostro hold invoice will expire. - `invoice_expiration_window`: The maximum time, in seconds, for a buyer to submit an invoice to Mostro. diff --git a/src/overview.md b/src/overview.md index 8d26287..225bc80 100644 --- a/src/overview.md +++ b/src/overview.md @@ -20,7 +20,7 @@ You can find more details about the order event [here](./order_event.md) Mostro messages travel over one of two interchangeable wire transports. A given node speaks **exactly one** of them — there is no dual mode — and advertises which in its [instance-info event](./other_events.md#mostro-instance-status) -(kind `38385`) through the `protocol_versions` tag (`"1"` or `"2"`): +(kind `38385`) through the `protocol_version` tag (`"1"` or `"2"`): | Protocol | Transport | Event kind | Status | |----------|-----------|------------|--------| @@ -30,7 +30,7 @@ advertises which in its [instance-info event](./other_events.md#mostro-instance- Both transports carry the **same logical message** and, once unwrapped, yield the same structure to the daemon's handlers — only the envelope and how the identity key is proven differ. Client developers should support -both during the transition and pick per node from the `protocol_versions` +both during the transition and pick per node from the `protocol_version` tag; see the [client migration guide](./transport_migration.md). The logical message itself (the first tuple element described below) is @@ -113,7 +113,7 @@ identity proof, NIP-44 encrypted inside a signed kind-`14` event: | element | meaning | |---|---| | 1 | the logical message (the `version: 2` wrapper shown above) | -| 2 | the trade key's signature over the serialized first element, or `null` (Mostro's own messages, and full-privacy mode, are unsigned — as in v1) | +| 2 | the trade key's signature over the serialized first element, or `null` (Mostro replies and full-privacy mode set this element to `null`; the outer kind-14 event is still signed, as in v1) | | 3 | the identity proof `["", ""]`, or `null` for full-privacy mode (where the identity is the trade key itself) | In v1 the identity key is carried, authenticated, by the gift-wrap *seal*. diff --git a/src/transport_migration.md b/src/transport_migration.md index 108298a..1f60135 100644 --- a/src/transport_migration.md +++ b/src/transport_migration.md @@ -28,10 +28,10 @@ pre-validation before decryption. See the threat model in A node speaks **exactly one** transport — there is no dual mode. It advertises which in its [instance-info event](./other_events.md#mostro-instance-status) -(kind `38385`) via the `protocol_versions` tag: +(kind `38385`) via the `protocol_version` tag: -- `["protocol_versions", "1"]` → gift wrap (kind `1059`) -- `["protocol_versions", "2"]` → NIP-44 direct (kind `14`) +- `["protocol_version", "1"]` → gift wrap (kind `1059`) +- `["protocol_version", "2"]` → NIP-44 direct (kind `14`) A client should read this tag **before** sending anything and use the matching wire format. Old daemons that predate the tag emit nothing; treat @@ -39,7 +39,7 @@ their absence as v1. ## What a client must change -1. **Read `protocol_versions`** from the node's kind-`38385` event and +1. **Read `protocol_version`** from the node's kind-`38385` event and branch on it. 2. **Subscribe to the right kind**: `1059` for v1, `14` for v2 (authored by the node, `#p`-tagged to your trade keys for node replies). @@ -72,6 +72,6 @@ include them to maintain reputation. longer accept kind-`1059` traffic. The recommendation is therefore: **keep both wrap paths now** and select per -node from `protocol_versions`. A client that supports both will work against +node from `protocol_version`. A client that supports both will work against every node throughout the transition, and against v2-only nodes after the v0.19.0 cutover with no further change.