docs: rename info tag protocol_versions -> protocol_version

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)

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.

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 `["<identity pubkey>", "<identity signature>"]`, 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*.

src/transport_migration.md

@@ -28,18 +28,18 @@ 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
 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.