From 24b1515df21bf3cd8a50b8ce665b1fe0fc3507df Mon Sep 17 00:00:00 2001 From: grunch Date: Tue, 28 Jul 2026 16:00:54 -0300 Subject: [PATCH 1/3] docs: update message examples to protocol version 2 All per-action JSON examples still showed "version": 1 even though protocol v2 (NIP-44 direct transport) is the current version and v1 is deprecated. Update every standalone message example to "version": 2. Deliberately kept at version 1: - overview.md v1-vs-v2 content-array comparison (illustrates v1) - key_management.md gift-wrap (kind 1059) walkthrough examples, which document the deprecated v1 envelope Also fix the stale note in last_trade_index.md that claimed the current protocol version is 1. --- src/add_bond_invoice.md | 8 ++++---- src/admin_add_solver.md | 6 +++--- src/admin_cancel_order.md | 6 +++--- src/admin_settle_order.md | 6 +++--- src/bond_slashed.md | 2 +- src/cancel.md | 14 +++++++------- src/dispute.md | 12 ++++++------ src/dispute_chat.md | 2 +- src/fiatsent.md | 8 ++++---- src/last_trade_index.md | 8 ++++---- src/new_buy_order.md | 4 ++-- src/new_buy_order_ln_address.md | 4 ++-- src/new_sell_order.md | 4 ++-- src/new_sell_range_order.md | 4 ++-- src/orders.md | 4 ++-- src/overview.md | 2 +- src/pay_bond_invoice.md | 4 ++-- src/payment_failed.md | 4 ++-- src/release.md | 12 ++++++------ src/restore_session.md | 6 +++--- src/seller_pay_hold_invoice.md | 12 ++++++------ src/take_buy.md | 12 ++++++------ src/take_buy_range_order.md | 2 +- src/take_sell.md | 8 ++++---- src/take_sell_ln_address.md | 4 ++-- src/take_sell_range_order.md | 6 +++--- src/user_rating.md | 6 +++--- 27 files changed, 85 insertions(+), 85 deletions(-) diff --git a/src/add_bond_invoice.md b/src/add_bond_invoice.md index c0f25f5..cb5a5cd 100644 --- a/src/add_bond_invoice.md +++ b/src/add_bond_invoice.md @@ -16,7 +16,7 @@ Mostro sends a single `add-bond-invoice` message to the non-slashed counterparty [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "add-bond-invoice", "payload": { @@ -64,7 +64,7 @@ The counterparty replies with a Gift wrap Nostr event whose rumor content carrie [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "add-bond-invoice", "payload": { @@ -111,7 +111,7 @@ Sent by Mostro to the counterparty immediately after successfully receiving and [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "bond-invoice-accepted", "payload": { @@ -141,7 +141,7 @@ Sent by Mostro to the counterparty when the Lightning payment to their invoice h [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "bond-payout-completed", "payload": { diff --git a/src/admin_add_solver.md b/src/admin_add_solver.md index ed24d64..2a3bef8 100644 --- a/src/admin_add_solver.md +++ b/src/admin_add_solver.md @@ -32,7 +32,7 @@ The default remains `read-write` for backward compatibility. [ { "order": { - "version": 1, + "version": 2, "action": "admin-add-solver", "payload": { "text_message": "npub1qqq884wtp2jn96lqhqlnarl4kk3rmvrc9z2nmrvqujx3m4l2ea5qd5d0fq" @@ -49,7 +49,7 @@ The default remains `read-write` for backward compatibility. [ { "order": { - "version": 1, + "version": 2, "action": "admin-add-solver", "payload": { "text_message": "npub1qqq884wtp2jn96lqhqlnarl4kk3rmvrc9z2nmrvqujx3m4l2ea5qd5d0fq:read" @@ -68,7 +68,7 @@ Mostro sends this message to the admin: [ { "order": { - "version": 1, + "version": 2, "action": "admin-add-solver", "payload": null } diff --git a/src/admin_cancel_order.md b/src/admin_cancel_order.md index 51714f0..0ee9258 100644 --- a/src/admin_cancel_order.md +++ b/src/admin_cancel_order.md @@ -6,7 +6,7 @@ An admin can cancel an order, most of the time this is done when admin is solvin [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "admin-cancel", "payload": null @@ -24,7 +24,7 @@ When solving a dispute, the admin can optionally slash one or both parties' bond [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "admin-cancel", "payload": { @@ -61,7 +61,7 @@ Mostro will send this message to the both parties buyer/seller and to the admin: [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "admin-canceled", "payload": null diff --git a/src/admin_settle_order.md b/src/admin_settle_order.md index 3801c74..b33284c 100644 --- a/src/admin_settle_order.md +++ b/src/admin_settle_order.md @@ -6,7 +6,7 @@ An admin can settle an order, most of the time this is done when admin is solvin [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "admin-settle", "payload": null @@ -24,7 +24,7 @@ When solving a dispute, the admin can optionally slash one or both parties' bond [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "admin-settle", "payload": { @@ -61,7 +61,7 @@ Mostro will send this message to the both parties buyer/seller and to the admin: [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "admin-settled", "payload": null diff --git a/src/bond_slashed.md b/src/bond_slashed.md index 54f2e25..0b147f8 100644 --- a/src/bond_slashed.md +++ b/src/bond_slashed.md @@ -16,7 +16,7 @@ The `bond-slashed` action is a notification Mostro sends to a bonded party when [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "bond-slashed", "payload": { diff --git a/src/cancel.md b/src/cancel.md index c039915..14e9d05 100644 --- a/src/cancel.md +++ b/src/cancel.md @@ -6,7 +6,7 @@ A user can cancel an order created by himself and with status `pending` sending [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "cancel", "payload": null @@ -24,7 +24,7 @@ Mostro will send a message with action `cancel` confirming the order was cancele [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "canceled", "payload": null @@ -97,7 +97,7 @@ A user can cancel an `active` order, but will need the counterparty to agree, le [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "cancel", "payload": null @@ -113,7 +113,7 @@ Mostro will send this message to the seller: [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "cooperative-cancel-initiated-by-you", "payload": null @@ -129,7 +129,7 @@ And this message to the buyer: [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "cooperative-cancel-initiated-by-peer", "payload": null @@ -145,7 +145,7 @@ The buyer can accept the cooperative cancellation sending this message: [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "cancel", "payload": null @@ -161,7 +161,7 @@ And Mostro will send this message to both parties: [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "cooperative-cancel-accepted", "payload": null diff --git a/src/dispute.md b/src/dispute.md index 68ea5f3..3f41b4e 100644 --- a/src/dispute.md +++ b/src/dispute.md @@ -6,7 +6,7 @@ A user can start a dispute in an order with status `active` or `fiat-sent` sendi [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "dispute", "payload": null @@ -24,7 +24,7 @@ Mostro will send this message to the seller: [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "dispute-initiated-by-you", "payload": { @@ -42,7 +42,7 @@ And here is the message to the buyer: [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "dispute-initiated-by-peer", "payload": { @@ -88,7 +88,7 @@ Mostro admin will see the dispute and can take it using the dispute `Id` from `d [ { "dispute": { - "version": 1, + "version": 2, "id": "", "action": "admin-take-dispute", "payload": null @@ -104,7 +104,7 @@ Mostro will send a confirmation message to the admin with the order details: [ { "dispute": { - "version": 1, + "version": 2, "id": "", "action": "admin-took-dispute", "payload": { @@ -135,7 +135,7 @@ Then mostrod send messages to each trade participant, the buyer and seller for t [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "admin-took-dispute", "payload": { diff --git a/src/dispute_chat.md b/src/dispute_chat.md index 95423e7..563828b 100644 --- a/src/dispute_chat.md +++ b/src/dispute_chat.md @@ -10,7 +10,7 @@ When an admin takes a dispute, Mostro sends an `admin-took-dispute` message to e [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "admin-took-dispute", "payload": { diff --git a/src/fiatsent.md b/src/fiatsent.md index 27d7f80..7a11ba6 100644 --- a/src/fiatsent.md +++ b/src/fiatsent.md @@ -5,7 +5,7 @@ After the buyer sends the fiat money to the seller, the buyer should send a mess ```json { "order": { - "version": 1, + "version": 2, "id": "", "action": "fiat-sent", "payload": null @@ -20,7 +20,7 @@ In most of the cases after complete a range order, a child order needs to be cre ```json { "order": { - "version": 1, + "version": 2, "id": "", "action": "fiat-sent", "payload": { @@ -37,7 +37,7 @@ Mostro send messages to both parties confirming `fiat-sent` action and sending a ```json { "order": { - "version": 1, + "version": 2, "id": "", "action": "fiat-sent-ok", "payload": { @@ -54,7 +54,7 @@ And here an example of the message from Mostro to the seller: ```json { "order": { - "version": 1, + "version": 2, "id": "", "pubkey": "", "action": "fiat-sent-ok", diff --git a/src/last_trade_index.md b/src/last_trade_index.md index 9bf87d6..797bfdb 100644 --- a/src/last_trade_index.md +++ b/src/last_trade_index.md @@ -10,7 +10,7 @@ Client sends a Gift wrap Nostr event to Mostro with the following rumor's conten [ { "restore": { - "version": 1, + "version": 2, "action": "last-trade-index", "payload": null } @@ -26,7 +26,7 @@ Mostro responds with the user's last trade index as a u32 directly in the `trade ```json { "restore": { - "version": 1, + "version": 2, "action": "last-trade-index", "trade_index": 42, "payload": null @@ -36,7 +36,7 @@ Mostro responds with the user's last trade index as a u32 directly in the `trade ### Fields -* `restore.version`: Protocol version. Current is `1`. +* `restore.version`: Protocol version — `1` on the gift-wrap transport (DEPRECATED), `2` on the NIP-44 direct transport. Current is `2`. * `restore.action`: Must be `last-trade-index`. * `restore.trade_index` (response): u32 representing the last `trade_index` for the user. `1` if none. * `restore.payload` (response): Must be `null`. @@ -48,7 +48,7 @@ Client requests the last trade index and receives `7`, meaning the next trade th ```json { "restore": { - "version": 1, + "version": 2, "action": "last-trade-index", "trade_index": 7, "payload": null diff --git a/src/new_buy_order.md b/src/new_buy_order.md index 0633c78..4b7a03b 100644 --- a/src/new_buy_order.md +++ b/src/new_buy_order.md @@ -5,7 +5,7 @@ To create a new buy order the user should send a Gift wrap Nostr event to Mostro ```json { "order": { - "version": 1, + "version": 2, "action": "new-order", "trade_index": 1, "payload": { @@ -56,7 +56,7 @@ Mostro will send back a nip59 event as a confirmation message, the message in th [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "new-order", "payload": { diff --git a/src/new_buy_order_ln_address.md b/src/new_buy_order_ln_address.md index 6279240..c1d2a0a 100644 --- a/src/new_buy_order_ln_address.md +++ b/src/new_buy_order_ln_address.md @@ -6,7 +6,7 @@ Creating buy order with a [lightning address](https://github.com/andrerfneves/li [ { "order": { - "version": 1, + "version": 2, "action": "new-order", "trade_index": 1, "payload": { @@ -50,7 +50,7 @@ Mostro will send back a nip59 event as a confirmation message to the user like t [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "new-order", "payload": { diff --git a/src/new_sell_order.md b/src/new_sell_order.md index cf89341..580c41c 100644 --- a/src/new_sell_order.md +++ b/src/new_sell_order.md @@ -5,7 +5,7 @@ To create a new sell order the user should send a Gift wrap Nostr event to Mostr ```json { "order": { - "version": 1, + "version": 2, "action": "new-order", "trade_index": 1, "payload": { @@ -65,7 +65,7 @@ Mostro will send back a nip59 event as a confirmation message to the user like t [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "new-order", "payload": { diff --git a/src/new_sell_range_order.md b/src/new_sell_range_order.md index c221718..65ae8be 100644 --- a/src/new_sell_range_order.md +++ b/src/new_sell_range_order.md @@ -5,7 +5,7 @@ To create a new range order the user should send a Gift wrap Nostr event to Most ```json { "order": { - "version": 1, + "version": 2, "action": "new-order", "trade_index": 1, "payload": { @@ -46,7 +46,7 @@ Mostro will send back a nip59 event as a confirmation message to the user like t [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "new-order", "payload": { diff --git a/src/orders.md b/src/orders.md index 8188921..b1bb864 100644 --- a/src/orders.md +++ b/src/orders.md @@ -10,7 +10,7 @@ The client sends a message where the payload object includes an `ids` array of o [ { "order": { - "version": 1, + "version": 2, "request_id": 8721, "action": "orders", "payload": { @@ -38,7 +38,7 @@ Mostro replies with the same action and includes a structured payload describing [ { "order": { - "version": 1, + "version": 2, "request_id": 8721, "action": "orders", "payload": { diff --git a/src/overview.md b/src/overview.md index 225bc80..a9f0f4b 100644 --- a/src/overview.md +++ b/src/overview.md @@ -63,7 +63,7 @@ Here an example of a `new-order` order **_message_**: ```json { "order": { - "version": 1, + "version": 2, "id": "", "request_id": 123456, "trade_index": 1, diff --git a/src/pay_bond_invoice.md b/src/pay_bond_invoice.md index 233bb65..003bbda 100644 --- a/src/pay_bond_invoice.md +++ b/src/pay_bond_invoice.md @@ -22,7 +22,7 @@ The message's content has the same shape as `pay-invoice`; only the action discr [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "pay-bond-invoice", "payload": { @@ -100,7 +100,7 @@ The action and wire shape are identical to the taker case: [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "pay-bond-invoice", "payload": { diff --git a/src/payment_failed.md b/src/payment_failed.md index d8d0035..fcfea99 100644 --- a/src/payment_failed.md +++ b/src/payment_failed.md @@ -12,7 +12,7 @@ When Mostro cannot pay the buyer's Lightning invoice, it sends this message to t [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "payment-failed", "payload": { @@ -46,7 +46,7 @@ When Mostro cannot pay the buyer's Lightning invoice, it sends this message to t [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "add-invoice", "payload": { diff --git a/src/release.md b/src/release.md index a299743..3778e40 100644 --- a/src/release.md +++ b/src/release.md @@ -6,7 +6,7 @@ After confirming the buyer sent the fiat money, the seller should send a message [ { "order": { - "version": 1, + "version": 2, "id": "", "request_id": "123456", "action": "release", @@ -25,7 +25,7 @@ Here an example of the Mostro response to the seller: [ { "order": { - "version": 1, + "version": 2, "id": "", "request_id": "123456", "action": "hold-invoice-payment-settled", @@ -42,7 +42,7 @@ And a message to the buyer to let him know that the sats were released: [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "released", "payload": null @@ -62,7 +62,7 @@ Right after seller releases sats, Mostro will attempt to pay the buyer's Lightni [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "purchase-completed", "payload": null @@ -112,7 +112,7 @@ If the order is a range order probably after release a child order would need to [ { "order": { - "version": 1, + "version": 2, "id": "4fd93fc9-e909-4fc9-acef-9976122b5dfa", "action": "release", "payload": { @@ -130,7 +130,7 @@ Mostro will send to the maker the newly child order created with the same `trade [ { "order": { - "version": 1, + "version": 2, "id": "4fd93fc9-e909-4fc9-acef-9976122b5dfa", "action": "new-order", "trade_index": , diff --git a/src/restore_session.md b/src/restore_session.md index 2e98be6..e943c39 100644 --- a/src/restore_session.md +++ b/src/restore_session.md @@ -10,7 +10,7 @@ Client sends a Gift wrap Nostr event to Mostro with the following rumor's conten [ { "restore": { - "version": 1, + "version": 2, "action": "restore-session", "payload": null } @@ -27,7 +27,7 @@ Mostro will respond with a message containing all non-finalized orders (e.g., st [ { "restore": { - "version": 1, + "version": 2, "action": "restore-session", "payload": { "restore_data": { @@ -85,7 +85,7 @@ When switching to desktop, after restoring the mnemonic, the client sends `resto [ { "restore": { - "version": 1, + "version": 2, "action": "restore-session", "payload": { "restore_data": { diff --git a/src/seller_pay_hold_invoice.md b/src/seller_pay_hold_invoice.md index 4930996..d8d99cd 100644 --- a/src/seller_pay_hold_invoice.md +++ b/src/seller_pay_hold_invoice.md @@ -6,7 +6,7 @@ When the seller is the maker and the order was taken by a buyer, Mostro will sen [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "pay-invoice", "payload": { @@ -37,7 +37,7 @@ After the hold invoice is paid and the buyer already sent the invoice to receive [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "buyer-took-order", "payload": { @@ -68,7 +68,7 @@ Mostro also send a message to the buyer, this way they can both write to each ot [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "hold-invoice-payment-accepted", "payload": { @@ -100,7 +100,7 @@ Mostro send this message to the seller: ```json { "order": { - "version": 1, + "version": 2, "id": "", "action": "waiting-buyer-invoice", "payload": null @@ -113,7 +113,7 @@ And this message to the buyer: ```json { "order": { - "version": 1, + "version": 2, "id": "", "action": "add-invoice", "payload": { @@ -138,7 +138,7 @@ Now buyer sends the invoice to Mostro: ```json { "order": { - "version": 1, + "version": 2, "id": "", "action": "add-invoice", "payload": { diff --git a/src/take_buy.md b/src/take_buy.md index ac829fc..0b29fdf 100644 --- a/src/take_buy.md +++ b/src/take_buy.md @@ -6,7 +6,7 @@ To take an order the seller will send to Mostro a message with the following rum [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "take-buy", "trade_index": 1, @@ -45,7 +45,7 @@ Mostro respond to the seller with a message with the following content: [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "pay-invoice", "payload": { @@ -108,7 +108,7 @@ And send a message to the buyer with the following content: [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "waiting-seller-to-pay", "payload": null @@ -126,7 +126,7 @@ After seller pays the hold invoice Mostro send a message to the seller with the [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "waiting-buyer-invoice", "payload": null @@ -141,7 +141,7 @@ Mostro sends a message to the buyer with the following content: [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "add-invoice", "payload": { @@ -170,7 +170,7 @@ Buyer sends the LN invoice to Mostro. [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "add-invoice", "payload": { diff --git a/src/take_buy_range_order.md b/src/take_buy_range_order.md index c363e6f..b861e53 100644 --- a/src/take_buy_range_order.md +++ b/src/take_buy_range_order.md @@ -6,7 +6,7 @@ If the order fiat amount is a range like `10-20` the seller must indicate a fiat [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "take-buy", "trade_index": 1, diff --git a/src/take_sell.md b/src/take_sell.md index 9fb5050..fa194a3 100644 --- a/src/take_sell.md +++ b/src/take_sell.md @@ -6,7 +6,7 @@ If the order amount is `0` the buyer doesn't know the exact amount to create the [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "take-sell", "trade_index": 1, @@ -29,7 +29,7 @@ In order to continue the buyer needs to send a lightning network invoice to Most [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "add-invoice", "payload": { @@ -90,7 +90,7 @@ The buyer sends a Gift wrap Nostr event to Mostro with the lightning invoice, th [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "add-invoice", "payload": { @@ -116,7 +116,7 @@ Mostro send a Gift wrap Nostr event to the buyer with a wrapped `order` in the r [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "waiting-seller-to-pay", "payload": null diff --git a/src/take_sell_ln_address.md b/src/take_sell_ln_address.md index 622ee6c..04631c1 100644 --- a/src/take_sell_ln_address.md +++ b/src/take_sell_ln_address.md @@ -6,7 +6,7 @@ The buyer can use a [lightning address](https://github.com/andrerfneves/lightnin [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "take-sell", "trade_index": 1, @@ -41,7 +41,7 @@ Mostro send a Gift wrap Nostr event to the buyer with a wrapped `order` in the r [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "waiting-seller-to-pay", "payload": null diff --git a/src/take_sell_range_order.md b/src/take_sell_range_order.md index 15f6f02..d96e2a3 100644 --- a/src/take_sell_range_order.md +++ b/src/take_sell_range_order.md @@ -6,7 +6,7 @@ If the order fiat amount is a range like `10-20` the buyer must indicate a fiat [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "take-sell", "trade_index": 1, @@ -27,7 +27,7 @@ In order to continue the buyer needs to send a lightning network invoice to Most [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "add-invoice", "payload": { @@ -93,7 +93,7 @@ The buyer can use a [lightning address](https://github.com/andrerfneves/lightnin [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "take-sell", "payload": { diff --git a/src/user_rating.md b/src/user_rating.md index d21f204..eb97d59 100644 --- a/src/user_rating.md +++ b/src/user_rating.md @@ -6,7 +6,7 @@ After a successful trade Mostro send a Gift wrap Nostr event to both parties to [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "rate", "payload": null @@ -22,7 +22,7 @@ After a Mostro client receive this message, the user can rate the other party, t [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "rate-user", "payload": { @@ -42,7 +42,7 @@ If Mostro received the correct message, it will send back a confirmation message [ { "order": { - "version": 1, + "version": 2, "id": "", "action": "rate-received", "payload": { From dc3fdeeec8add59dc509143ffe6320211d22d14e Mon Sep 17 00:00:00 2001 From: grunch Date: Wed, 29 Jul 2026 15:06:56 -0300 Subject: [PATCH 2/3] docs: migrate v2 examples to NIP-44 direct transport Address review feedback on PR #51: examples were relabeled version 2 but kept the v1 Gift Wrap transport. Now every changed page uses the real v2 wire format: - content tuples gain the third identity-proof element (identity proof for signed user requests, null for Mostro replies and full privacy) - kind 1059 event examples become signed kind 14 events authored by the trade key, with NIP-44 ciphertext content and NIP-40 expiration tag - prose no longer references Gift Wrap / NIP-59 / rumors on v2 pages - Mostro-reply examples that wrongly showed a trade-key signature now carry null, per overview.md content-array rules dispute_chat.md keeps its kind 1059 sections: they document the separate shared-key chat scheme from chat.md, not the Mostro message transport. --- src/add_bond_invoice.md | 8 ++++++-- src/admin_add_solver.md | 3 +++ src/admin_cancel_order.md | 3 +++ src/admin_settle_order.md | 3 +++ src/bond_slashed.md | 1 + src/cancel.md | 13 ++++++++++--- src/dispute.md | 8 +++++++- src/dispute_chat.md | 1 + src/fiatsent.md | 2 +- src/last_trade_index.md | 3 ++- src/new_buy_order.md | 18 +++++++++++------- src/new_buy_order_ln_address.md | 21 +++++++++++++-------- src/new_sell_order.md | 18 +++++++++++------- src/new_sell_range_order.md | 5 +++-- src/orders.md | 4 +++- src/pay_bond_invoice.md | 2 ++ src/payment_failed.md | 2 ++ src/release.md | 8 +++++++- src/restore_session.md | 5 ++++- src/seller_pay_hold_invoice.md | 11 +++++++---- src/take_buy.md | 23 ++++++++++++++++------- src/take_buy_range_order.md | 3 ++- src/take_sell.md | 16 ++++++++++------ src/take_sell_ln_address.md | 23 ++++++++++++++--------- src/take_sell_range_order.md | 11 +++++++---- src/user_rating.md | 7 +++++-- 26 files changed, 154 insertions(+), 68 deletions(-) diff --git a/src/add_bond_invoice.md b/src/add_bond_invoice.md index cb5a5cd..edf7efd 100644 --- a/src/add_bond_invoice.md +++ b/src/add_bond_invoice.md @@ -35,6 +35,7 @@ Mostro sends a single `add-bond-invoice` message to the non-slashed counterparty } } }, + null, null ] ``` @@ -58,7 +59,7 @@ deadline = slashed_at + bond_payout_claim_window_days * 86_400 ## Counterparty → Mostro (reply) -The counterparty replies with a Gift wrap Nostr event whose rumor content carries the bolt11 inside the standard `payment_request` array. The invoice carries its own amount, so the array has two elements (per [Payment Request Array Structure](./overview.md#payment-request-array-structure)): +The counterparty replies with a NIP-44 direct message (kind `14`) whose decrypted content carries the bolt11 inside the standard `payment_request` array. The invoice carries its own amount, so the array has two elements (per [Payment Request Array Structure](./overview.md#payment-request-array-structure)): ```json [ @@ -75,7 +76,8 @@ The counterparty replies with a Gift wrap Nostr event whose rumor content carrie } } }, - "" + "", + ["", ""] ] ``` @@ -127,6 +129,7 @@ Sent by Mostro to the counterparty immediately after successfully receiving and } } }, + null, null ] ``` @@ -157,6 +160,7 @@ Sent by Mostro to the counterparty when the Lightning payment to their invoice h } } }, + null, null ] ``` diff --git a/src/admin_add_solver.md b/src/admin_add_solver.md index 2a3bef8..1677591 100644 --- a/src/admin_add_solver.md +++ b/src/admin_add_solver.md @@ -39,6 +39,7 @@ The default remains `read-write` for backward compatibility. } } }, + null, null ] ``` @@ -56,6 +57,7 @@ The default remains `read-write` for backward compatibility. } } }, + null, null ] ``` @@ -73,6 +75,7 @@ Mostro sends this message to the admin: "payload": null } }, + null, null ] ``` diff --git a/src/admin_cancel_order.md b/src/admin_cancel_order.md index 0ee9258..ea3e0b5 100644 --- a/src/admin_cancel_order.md +++ b/src/admin_cancel_order.md @@ -12,6 +12,7 @@ An admin can cancel an order, most of the time this is done when admin is solvin "payload": null } }, + null, null ] ``` @@ -35,6 +36,7 @@ When solving a dispute, the admin can optionally slash one or both parties' bond } } }, + null, null ] ``` @@ -67,6 +69,7 @@ Mostro will send this message to the both parties buyer/seller and to the admin: "payload": null } }, + null, null ] ``` diff --git a/src/admin_settle_order.md b/src/admin_settle_order.md index b33284c..96d41e0 100644 --- a/src/admin_settle_order.md +++ b/src/admin_settle_order.md @@ -12,6 +12,7 @@ An admin can settle an order, most of the time this is done when admin is solvin "payload": null } }, + null, null ] ``` @@ -35,6 +36,7 @@ When solving a dispute, the admin can optionally slash one or both parties' bond } } }, + null, null ] ``` @@ -67,6 +69,7 @@ Mostro will send this message to the both parties buyer/seller and to the admin: "payload": null } }, + null, null ] ``` diff --git a/src/bond_slashed.md b/src/bond_slashed.md index 0b147f8..83690a9 100644 --- a/src/bond_slashed.md +++ b/src/bond_slashed.md @@ -34,6 +34,7 @@ The `bond-slashed` action is a notification Mostro sends to a bonded party when } } }, + null, null ] ``` diff --git a/src/cancel.md b/src/cancel.md index 14e9d05..69493ba 100644 --- a/src/cancel.md +++ b/src/cancel.md @@ -1,6 +1,6 @@ # Cancel Order -A user can cancel an order created by himself and with status `pending` sending action `cancel`, the rumor's content of the message will look like this: +A user can cancel an order created by himself and with status `pending` sending action `cancel`, the decrypted content of the message will look like this: ```json [ @@ -12,13 +12,14 @@ A user can cancel an order created by himself and with status `pending` sending "payload": null } }, - "" + "", + ["", ""] ] ``` ## Mostro response -Mostro will send a message with action `cancel` confirming the order was canceled, here an example of rumor's content of the message: +Mostro will send a message with action `cancel` confirming the order was canceled, here an example of decrypted content of the message: ```json [ @@ -30,6 +31,7 @@ Mostro will send a message with action `cancel` confirming the order was cancele "payload": null } }, + null, null ] ``` @@ -103,6 +105,7 @@ A user can cancel an `active` order, but will need the counterparty to agree, le "payload": null } }, + null, null ] ``` @@ -119,6 +122,7 @@ Mostro will send this message to the seller: "payload": null } }, + null, null ] ``` @@ -135,6 +139,7 @@ And this message to the buyer: "payload": null } }, + null, null ] ``` @@ -151,6 +156,7 @@ The buyer can accept the cooperative cancellation sending this message: "payload": null } }, + null, null ] ``` @@ -167,6 +173,7 @@ And Mostro will send this message to both parties: "payload": null } }, + null, null ] ``` diff --git a/src/dispute.md b/src/dispute.md index 3f41b4e..8231348 100644 --- a/src/dispute.md +++ b/src/dispute.md @@ -12,7 +12,8 @@ A user can start a dispute in an order with status `active` or `fiat-sent` sendi "payload": null } }, - "" + "", + ["", ""] ] ``` @@ -32,6 +33,7 @@ Mostro will send this message to the seller: } } }, + null, null ] ``` @@ -50,6 +52,7 @@ And here is the message to the buyer: } } }, + null, null ] ``` @@ -94,6 +97,7 @@ Mostro admin will see the dispute and can take it using the dispute `Id` from `d "payload": null } }, + null, null ] ``` @@ -125,6 +129,7 @@ Mostro will send a confirmation message to the admin with the order details: } } }, + null, null ] ``` @@ -145,6 +150,7 @@ Then mostrod send messages to each trade participant, the buyer and seller for t } } }, + null, null ] ``` diff --git a/src/dispute_chat.md b/src/dispute_chat.md index 563828b..be70a75 100644 --- a/src/dispute_chat.md +++ b/src/dispute_chat.md @@ -20,6 +20,7 @@ When an admin takes a dispute, Mostro sends an `admin-took-dispute` message to e } } }, + null, null ] ``` diff --git a/src/fiatsent.md b/src/fiatsent.md index 7a11ba6..bd11cb6 100644 --- a/src/fiatsent.md +++ b/src/fiatsent.md @@ -1,6 +1,6 @@ # Fiat sent -After the buyer sends the fiat money to the seller, the buyer should send a message in a Gift wrap Nostr event to Mostro indicating that the fiat money was sent, message in the first element of the rumor's content would look like this: +After the buyer sends the fiat money to the seller, the buyer should send a message in a NIP-44 direct message (kind `14`) to Mostro indicating that the fiat money was sent, message in the first element of the decrypted content would look like this: ```json { diff --git a/src/last_trade_index.md b/src/last_trade_index.md index 797bfdb..7511609 100644 --- a/src/last_trade_index.md +++ b/src/last_trade_index.md @@ -4,7 +4,7 @@ Defines the `last-trade-index` action used to retrieve the user's last `trade_in ## Request -Client sends a Gift wrap Nostr event to Mostro with the following rumor's content. The request sends a `null` payload to indicate that the client is querying for the last trade index. +Client sends a NIP-44 direct message (kind `14`) to Mostro with the following decrypted content. The request sends a `null` payload to indicate that the client is querying for the last trade index. ```json [ @@ -15,6 +15,7 @@ Client sends a Gift wrap Nostr event to Mostro with the following rumor's conten "payload": null } }, + null, null ] ``` diff --git a/src/new_buy_order.md b/src/new_buy_order.md index 4b7a03b..a7748da 100644 --- a/src/new_buy_order.md +++ b/src/new_buy_order.md @@ -1,6 +1,6 @@ # Creating a new buy order -To create a new buy order the user should send a Gift wrap Nostr event to Mostro with the following message: +To create a new buy order the user should send a NIP-44 direct message (kind `14`) to Mostro with the following message: ```json { @@ -29,12 +29,15 @@ The nostr event will look like this: ```json { "id": "", - "kind": 1059, - "pubkey": "", - "content": "", - "tags": [["p", "Mostro's pubkey"]], + "kind": 14, + "pubkey": "", + "content": "", + "tags": [ + ["p", ""], + ["expiration", ""] + ], "created_at": 1234567890, - "sig": "" + "sig": "" } ``` @@ -50,7 +53,7 @@ If the maker never pays the bond invoice it expires and no order is created. See ## Confirmation message -Mostro will send back a nip59 event as a confirmation message, the message in the rumor looks like the following: +Mostro will send back a kind `14` event as a confirmation message, the decrypted content looks like the following: ```json [ @@ -77,6 +80,7 @@ Mostro will send back a nip59 event as a confirmation message, the message in th } } }, + null, null ] ``` diff --git a/src/new_buy_order_ln_address.md b/src/new_buy_order_ln_address.md index c1d2a0a..9087a22 100644 --- a/src/new_buy_order_ln_address.md +++ b/src/new_buy_order_ln_address.md @@ -1,6 +1,6 @@ # Creating a new order -Creating buy order with a [lightning address](https://github.com/andrerfneves/lightning-address) would make the process way faster and easy going, to acomplish the buyer should send a Gift wrap Nostr event to Mostro with the following rumor's content: +Creating buy order with a [lightning address](https://github.com/andrerfneves/lightning-address) would make the process way faster and easy going, to acomplish the buyer should send a NIP-44 direct message (kind `14`) to Mostro with the following decrypted content: ```json [ @@ -24,7 +24,8 @@ Creating buy order with a [lightning address](https://github.com/andrerfneves/li } } }, - "" + "", + ["", ""] ] ``` @@ -33,18 +34,21 @@ The nostr event will look like this: ```json { "id": "", - "kind": 1059, - "pubkey": "", - "content": "", - "tags": [["p", "Mostro's pubkey"]], + "kind": 14, + "pubkey": "", + "content": "", + "tags": [ + ["p", ""], + ["expiration", ""] + ], "created_at": 1234567890, - "sig": "" + "sig": "" } ``` ## Confirmation message -Mostro will send back a nip59 event as a confirmation message to the user like the following: +Mostro will send back a kind `14` event as a confirmation message to the user like the following: ```json [ @@ -71,6 +75,7 @@ Mostro will send back a nip59 event as a confirmation message to the user like t } } }, + null, null ] ``` diff --git a/src/new_sell_order.md b/src/new_sell_order.md index 580c41c..2655ea6 100644 --- a/src/new_sell_order.md +++ b/src/new_sell_order.md @@ -1,6 +1,6 @@ # Creating a new sell order -To create a new sell order the user should send a Gift wrap Nostr event to Mostro, the message should look like this: +To create a new sell order the user should send a NIP-44 direct message (kind `14`) to Mostro, the message should look like this: ```json { @@ -38,12 +38,15 @@ The event to send to Mostro would look like this: ```json { "id": "", - "kind": 1059, - "pubkey": "", - "content": "", - "tags": [["p", "Mostro's pubkey"]], + "kind": 14, + "pubkey": "", + "content": "", + "tags": [ + ["p", ""], + ["expiration", ""] + ], "created_at": 1234567890, - "sig": "" + "sig": "" } ``` @@ -59,7 +62,7 @@ If the maker never pays the bond invoice it expires and no order is created. See ## Confirmation message -Mostro will send back a nip59 event as a confirmation message to the user like the following (unencrypted rumor's content example): +Mostro will send back a kind `14` event as a confirmation message to the user like the following (decrypted content example): ```json [ @@ -83,6 +86,7 @@ Mostro will send back a nip59 event as a confirmation message to the user like t } } }, + null, null ] ``` diff --git a/src/new_sell_range_order.md b/src/new_sell_range_order.md index 65ae8be..956dcba 100644 --- a/src/new_sell_range_order.md +++ b/src/new_sell_range_order.md @@ -1,6 +1,6 @@ # Creating a new sell range order -To create a new range order the user should send a Gift wrap Nostr event to Mostro with the following message: +To create a new range order the user should send a NIP-44 direct message (kind `14`) to Mostro with the following message: ```json { @@ -40,7 +40,7 @@ When a taker takes a slice of the range order, the bond obligation is reduced pr ## Confirmation message -Mostro will send back a nip59 event as a confirmation message to the user like the following: +Mostro will send back a kind `14` event as a confirmation message to the user like the following: ```json [ @@ -66,6 +66,7 @@ Mostro will send back a nip59 event as a confirmation message to the user like t } } }, + null, null ] ``` diff --git a/src/orders.md b/src/orders.md index b1bb864..3719037 100644 --- a/src/orders.md +++ b/src/orders.md @@ -1,6 +1,6 @@ # Request order details -Clients can request detailed information for existing orders by sending a nip59 Gift wrap message with the action `orders`. This is useful for refreshing stale UI state or restoring a session from the mnemonic seed on a new device. +Clients can request detailed information for existing orders by sending a NIP-44 direct message (kind `14`) with the action `orders`. This is useful for refreshing stale UI state or restoring a session from the mnemonic seed on a new device. ## Request message @@ -21,6 +21,7 @@ The client sends a message where the payload object includes an `ids` array of o } } }, + null, null ] ``` @@ -79,6 +80,7 @@ Mostro replies with the same action and includes a structured payload describing } } }, + null, null ] ``` diff --git a/src/pay_bond_invoice.md b/src/pay_bond_invoice.md index 003bbda..b371b13 100644 --- a/src/pay_bond_invoice.md +++ b/src/pay_bond_invoice.md @@ -43,6 +43,7 @@ The message's content has the same shape as `pay-invoice`; only the action discr } } }, + null, null ] ``` @@ -121,6 +122,7 @@ The action and wire shape are identical to the taker case: } } }, + null, null ] ``` diff --git a/src/payment_failed.md b/src/payment_failed.md index fcfea99..2aa29bc 100644 --- a/src/payment_failed.md +++ b/src/payment_failed.md @@ -23,6 +23,7 @@ When Mostro cannot pay the buyer's Lightning invoice, it sends this message to t } } }, + null, null ] ``` @@ -58,6 +59,7 @@ When Mostro cannot pay the buyer's Lightning invoice, it sends this message to t } } }, + null, null ] ``` diff --git a/src/release.md b/src/release.md index 3778e40..0e4c976 100644 --- a/src/release.md +++ b/src/release.md @@ -1,6 +1,6 @@ # Release -After confirming the buyer sent the fiat money, the seller should send a message to Mostro indicating that sats should be delivered to the buyer, the message inside rumor's content will look like this: +After confirming the buyer sent the fiat money, the seller should send a message to Mostro indicating that sats should be delivered to the buyer, the message inside decrypted content will look like this: ```json [ @@ -13,6 +13,7 @@ After confirming the buyer sent the fiat money, the seller should send a message "payload": null } }, + null, null ] ``` @@ -32,6 +33,7 @@ Here an example of the Mostro response to the seller: "payload": null } }, + null, null ] ``` @@ -48,6 +50,7 @@ And a message to the buyer to let him know that the sats were released: "payload": null } }, + null, null ] ``` @@ -68,6 +71,7 @@ Right after seller releases sats, Mostro will attempt to pay the buyer's Lightni "payload": null } }, + null, null ] ``` @@ -120,6 +124,7 @@ If the order is a range order probably after release a child order would need to } } }, + null, null ] ``` @@ -153,6 +158,7 @@ Mostro will send to the maker the newly child order created with the same `trade } } }, + null, null ] ``` diff --git a/src/restore_session.md b/src/restore_session.md index e943c39..948b9ee 100644 --- a/src/restore_session.md +++ b/src/restore_session.md @@ -4,7 +4,7 @@ To restore a session from the mnemonic seed on a new device (e.g., moving from m ## Request -Client sends a Gift wrap Nostr event to Mostro with the following rumor's content: +Client sends a NIP-44 direct message (kind `14`) to Mostro with the following decrypted content: ```json [ @@ -15,6 +15,7 @@ Client sends a Gift wrap Nostr event to Mostro with the following rumor's conten "payload": null } }, + null, null ] ``` @@ -61,6 +62,7 @@ Mostro will respond with a message containing all non-finalized orders (e.g., st } } }, + null, null ] ``` @@ -102,6 +104,7 @@ When switching to desktop, after restoring the mnemonic, the client sends `resto } } }, + null, null ] ``` diff --git a/src/seller_pay_hold_invoice.md b/src/seller_pay_hold_invoice.md index d8d99cd..290e776 100644 --- a/src/seller_pay_hold_invoice.md +++ b/src/seller_pay_hold_invoice.md @@ -1,6 +1,6 @@ # Seller pays hold invoice -When the seller is the maker and the order was taken by a buyer, Mostro will send to the seller a message asking to pay the hold invoice, the rumor's content of the message will look like this: +When the seller is the maker and the order was taken by a buyer, Mostro will send to the seller a message asking to pay the hold invoice, the decrypted content of the message will look like this: ```json [ @@ -27,11 +27,12 @@ When the seller is the maker and the order was taken by a buyer, Mostro will sen } } }, - "" + null, + null ] ``` -After the hold invoice is paid and the buyer already sent the invoice to receive the sats, Mostro will send a new message to seller with the following rumor's content: +After the hold invoice is paid and the buyer already sent the invoice to receive the sats, Mostro will send a new message to seller with the following decrypted content: ```json [ @@ -58,7 +59,8 @@ After the hold invoice is paid and the buyer already sent the invoice to receive } } }, - "" + null, + null ] ``` @@ -89,6 +91,7 @@ Mostro also send a message to the buyer, this way they can both write to each ot } } }, + null, null ] ``` diff --git a/src/take_buy.md b/src/take_buy.md index 0b29fdf..f98732a 100644 --- a/src/take_buy.md +++ b/src/take_buy.md @@ -1,6 +1,6 @@ # Taking a buy order -To take an order the seller will send to Mostro a message with the following rumor's content: +To take an order the seller will send to Mostro a message with the following decrypted content: ```json [ @@ -13,7 +13,8 @@ To take an order the seller will send to Mostro a message with the following rum "payload": null } }, - "" + "", + ["", ""] ] ``` @@ -22,12 +23,15 @@ The event to send to Mostro would look like this: ```json { "id": "", - "kind": 1059, - "pubkey": "", - "content": "", - "tags": [["p", "Mostro's pubkey"]], + "kind": 14, + "pubkey": "", + "content": "", + "tags": [ + ["p", ""], + ["expiration", ""] + ], "created_at": 1234567890, - "sig": "" + "sig": "" } ``` @@ -66,6 +70,7 @@ Mostro respond to the seller with a message with the following content: } } }, + null, null ] ``` @@ -114,6 +119,7 @@ And send a message to the buyer with the following content: "payload": null } }, + null, null ] ``` @@ -132,6 +138,7 @@ After seller pays the hold invoice Mostro send a message to the seller with the "payload": null } }, + null, null ] ``` @@ -158,6 +165,7 @@ Mostro sends a message to the buyer with the following content: } } }, + null, null ] ``` @@ -181,6 +189,7 @@ Buyer sends the LN invoice to Mostro. } } }, + null, null ] ``` diff --git a/src/take_buy_range_order.md b/src/take_buy_range_order.md index b861e53..fe9644d 100644 --- a/src/take_buy_range_order.md +++ b/src/take_buy_range_order.md @@ -1,6 +1,6 @@ # Taking a buy range order -If the order fiat amount is a range like `10-20` the seller must indicate a fiat amount to take the order, seller will send a message in a Gift wrap Nostr event to Mostro with the following rumor's content: +If the order fiat amount is a range like `10-20` the seller must indicate a fiat amount to take the order, seller will send a message in a NIP-44 direct message (kind `14`) to Mostro with the following decrypted content: ```json [ @@ -15,6 +15,7 @@ If the order fiat amount is a range like `10-20` the seller must indicate a fiat } } }, + null, null ] ``` diff --git a/src/take_sell.md b/src/take_sell.md index fa194a3..3f4c579 100644 --- a/src/take_sell.md +++ b/src/take_sell.md @@ -1,6 +1,6 @@ # Taking a sell order -If the order amount is `0` the buyer doesn't know the exact amount to create the invoice, buyer will send a message in a Gift wrap Nostr event to Mostro with the following rumor's content: +If the order amount is `0` the buyer doesn't know the exact amount to create the invoice, buyer will send a message in a NIP-44 direct message (kind `14`) to Mostro with the following decrypted content: ```json [ @@ -13,7 +13,8 @@ If the order amount is `0` the buyer doesn't know the exact amount to create the "payload": null } }, - "" + "", + ["", ""] ] ``` @@ -23,7 +24,7 @@ When the receiving Mostro node has bonds enabled, the buyer (taker) first receiv ## Mostro response -In order to continue the buyer needs to send a lightning network invoice to Mostro, in this case the amount of the order is `0`, so Mostro will need to calculate the amount of sats for this order, then Mostro will send back a message asking for a LN invoice indicating the correct amount of sats that the invoice should have, here the rumor's content of the message: +In order to continue the buyer needs to send a lightning network invoice to Mostro, in this case the amount of the order is `0`, so Mostro will need to calculate the amount of sats for this order, then Mostro will send back a message asking for a LN invoice indicating the correct amount of sats that the invoice should have, here the decrypted content of the message: ```json [ @@ -46,6 +47,7 @@ In order to continue the buyer needs to send a lightning network invoice to Most } } }, + null, null ] ``` @@ -84,7 +86,7 @@ Mostro updates the addressable event with `d` tag `` to change the sta ## Buyer sends LN invoice -The buyer sends a Gift wrap Nostr event to Mostro with the lightning invoice, the action should be the same the buyer just received in the last message from Mostro (`add-invoice`), here the rumor's content of the event for an invoice with no amount: +The buyer sends a NIP-44 direct message (kind `14`) to Mostro with the lightning invoice, the action should be the same the buyer just received in the last message from Mostro (`add-invoice`), here the decrypted content of the event for an invoice with no amount: ```json [ @@ -102,7 +104,8 @@ The buyer sends a Gift wrap Nostr event to Mostro with the lightning invoice, th } } }, - "" + "", + ["", ""] ] ``` @@ -110,7 +113,7 @@ If the invoice includes an amount, the last element of the `payment_request` arr ## Mostro response -Mostro send a Gift wrap Nostr event to the buyer with a wrapped `order` in the rumor's content, it would look like this: +Mostro send a NIP-44 direct message (kind `14`) to the buyer with a wrapped `order` in the decrypted content, it would look like this: ```json [ @@ -122,6 +125,7 @@ Mostro send a Gift wrap Nostr event to the buyer with a wrapped `order` in the r "payload": null } }, + null, null ] ``` diff --git a/src/take_sell_ln_address.md b/src/take_sell_ln_address.md index 04631c1..131733b 100644 --- a/src/take_sell_ln_address.md +++ b/src/take_sell_ln_address.md @@ -1,6 +1,6 @@ # Taking a sell order with a lightning address -The buyer can use a [lightning address](https://github.com/andrerfneves/lightning-address) to receive funds and avoid to manually create and send lightning invoices on each trade, to acomplish this the buyer will send a message in a Gift wrap Nostr event to Mostro with the following rumor's content: +The buyer can use a [lightning address](https://github.com/andrerfneves/lightning-address) to receive funds and avoid to manually create and send lightning invoices on each trade, to acomplish this the buyer will send a message in a NIP-44 direct message (kind `14`) to Mostro with the following decrypted content: ```json [ @@ -15,7 +15,8 @@ The buyer can use a [lightning address](https://github.com/andrerfneves/lightnin } } }, - "" + "", + ["", ""] ] ``` @@ -24,18 +25,21 @@ The event to send to Mostro would look like this: ```json { "id": "", - "kind": 1059, - "pubkey": "", - "content": "", - "tags": [["p", "Mostro's pubkey"]], + "kind": 14, + "pubkey": "", + "content": "", + "tags": [ + ["p", ""], + ["expiration", ""] + ], "created_at": 1234567890, - "sig": "" + "sig": "" } ``` ## Mostro response -Mostro send a Gift wrap Nostr event to the buyer with a wrapped `order` in the rumor's content, it would look like this: +Mostro send a NIP-44 direct message (kind `14`) to the buyer with a wrapped `order` in the decrypted content, it would look like this: ```json [ @@ -47,7 +51,8 @@ Mostro send a Gift wrap Nostr event to the buyer with a wrapped `order` in the r "payload": null } }, - "" + null, + null ] ``` diff --git a/src/take_sell_range_order.md b/src/take_sell_range_order.md index d96e2a3..3f8a47e 100644 --- a/src/take_sell_range_order.md +++ b/src/take_sell_range_order.md @@ -1,6 +1,6 @@ # Taking a sell range order -If the order fiat amount is a range like `10-20` the buyer must indicate a fiat amount to take the order, buyer will send a message in a Gift wrap Nostr event to Mostro with the following rumor's content: +If the order fiat amount is a range like `10-20` the buyer must indicate a fiat amount to take the order, buyer will send a message in a NIP-44 direct message (kind `14`) to Mostro with the following decrypted content: ```json [ @@ -15,13 +15,14 @@ If the order fiat amount is a range like `10-20` the buyer must indicate a fiat } } }, - "" + "", + ["", ""] ] ``` ## Mostro response -In order to continue the buyer needs to send a lightning network invoice to Mostro, in this case the amount of the order is `0`, so Mostro will need to calculate the amount of sats for this order, then Mostro will send back a message asking for a LN invoice indicating the correct amount of sats that the invoice should have, here the rumor's content of the message: +In order to continue the buyer needs to send a lightning network invoice to Mostro, in this case the amount of the order is `0`, so Mostro will need to calculate the amount of sats for this order, then Mostro will send back a message asking for a LN invoice indicating the correct amount of sats that the invoice should have, here the decrypted content of the message: ```json [ @@ -49,6 +50,7 @@ In order to continue the buyer needs to send a lightning network invoice to Most } } }, + null, null ] ``` @@ -87,7 +89,7 @@ Mostro updates the addressable event with `d` tag `` to change the sta ## Using a lightning address -The buyer can use a [lightning address](https://github.com/andrerfneves/lightning-address) to receive funds and avoid to create and send lightning invoices on each trade, with a range order we set the fiat amount as the third element of the `payment_request` array, to acomplish this the buyer will send a message in a Gift wrap Nostr event to Mostro with the following rumor's content: +The buyer can use a [lightning address](https://github.com/andrerfneves/lightning-address) to receive funds and avoid to create and send lightning invoices on each trade, with a range order we set the fiat amount as the third element of the `payment_request` array, to acomplish this the buyer will send a message in a NIP-44 direct message (kind `14`) to Mostro with the following decrypted content: ```json [ @@ -101,6 +103,7 @@ The buyer can use a [lightning address](https://github.com/andrerfneves/lightnin } } }, + null, null ] ``` diff --git a/src/user_rating.md b/src/user_rating.md index eb97d59..b41e7b1 100644 --- a/src/user_rating.md +++ b/src/user_rating.md @@ -1,6 +1,6 @@ # User rating -After a successful trade Mostro send a Gift wrap Nostr event to both parties to let them know they can rate each other, here an example how the message look like: +After a successful trade Mostro send a NIP-44 direct message (kind `14`) to both parties to let them know they can rate each other, here an example how the message look like: ```json [ @@ -12,11 +12,12 @@ After a successful trade Mostro send a Gift wrap Nostr event to both parties to "payload": null } }, + null, null ] ``` -After a Mostro client receive this message, the user can rate the other party, the rating is a number between 1 and 5, to rate the client must receive user's input and create a new Gift wrap Nostr event to send to Mostro with this content: +After a Mostro client receive this message, the user can rate the other party, the rating is a number between 1 and 5, to rate the client must receive user's input and create a new NIP-44 direct message (kind `14`) to send to Mostro with this content: ```json [ @@ -30,6 +31,7 @@ After a Mostro client receive this message, the user can rate the other party, t } } }, + null, null ] ``` @@ -50,6 +52,7 @@ If Mostro received the correct message, it will send back a confirmation message } } }, + null, null ] ``` From 2eaa0f39054f613f857639a05e47a3aca03bdb60 Mon Sep 17 00:00:00 2001 From: grunch Date: Wed, 29 Jul 2026 15:36:21 -0300 Subject: [PATCH 3/3] =?UTF-8?q?docs:=20address=20review=20nits=20=E2=80=94?= =?UTF-8?q?=20request=20tuples,=20wording=20fixes?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - new_buy_order.md, new_sell_order.md: wrap the request example in the full 3-element v2 content tuple, matching the lightning-address page - take_sell_range_order.md: the sats amount comes from the buyer's selected fiat amount, not from a zero order amount; grammar fixes - cancel.md: 'Mostro response' -> 'Mostro's response' --- src/cancel.md | 2 +- src/new_buy_order.md | 40 +++++++++++++++++--------------- src/new_sell_order.md | 44 ++++++++++++++++++++---------------- src/take_sell_range_order.md | 4 ++-- 4 files changed, 49 insertions(+), 41 deletions(-) diff --git a/src/cancel.md b/src/cancel.md index 69493ba..05d5cbe 100644 --- a/src/cancel.md +++ b/src/cancel.md @@ -17,7 +17,7 @@ A user can cancel an order created by himself and with status `pending` sending ] ``` -## Mostro response +## Mostro's response Mostro will send a message with action `cancel` confirming the order was canceled, here an example of decrypted content of the message: diff --git a/src/new_buy_order.md b/src/new_buy_order.md index a7748da..6c5f635 100644 --- a/src/new_buy_order.md +++ b/src/new_buy_order.md @@ -1,27 +1,31 @@ # Creating a new buy order -To create a new buy order the user should send a NIP-44 direct message (kind `14`) to Mostro with the following message: +To create a new buy order the user should send a NIP-44 direct message (kind `14`) to Mostro with the following decrypted content: ```json -{ - "order": { - "version": 2, - "action": "new-order", - "trade_index": 1, - "payload": { - "order": { - "kind": "buy", - "status": "pending", - "amount": 0, - "fiat_code": "VES", - "fiat_amount": 100, - "payment_method": "face to face", - "premium": 1, - "created_at": 0 +[ + { + "order": { + "version": 2, + "action": "new-order", + "trade_index": 1, + "payload": { + "order": { + "kind": "buy", + "status": "pending", + "amount": 0, + "fiat_code": "VES", + "fiat_amount": 100, + "payment_method": "face to face", + "premium": 1, + "created_at": 0 + } } } - } -} + }, + "", + ["", ""] +] ``` The nostr event will look like this: diff --git a/src/new_sell_order.md b/src/new_sell_order.md index 2655ea6..1820b3f 100644 --- a/src/new_sell_order.md +++ b/src/new_sell_order.md @@ -1,29 +1,33 @@ # Creating a new sell order -To create a new sell order the user should send a NIP-44 direct message (kind `14`) to Mostro, the message should look like this: +To create a new sell order the user should send a NIP-44 direct message (kind `14`) to Mostro, the decrypted content should look like this: ```json -{ - "order": { - "version": 2, - "action": "new-order", - "trade_index": 1, - "payload": { - "order": { - "kind": "sell", - "status": "pending", - "amount": 0, - "fiat_code": "VES", - "min_amount": null, - "max_amount": null, - "fiat_amount": 100, - "payment_method": "face to face,bank transfer,mobile", - "premium": 1, - "created_at": 0 +[ + { + "order": { + "version": 2, + "action": "new-order", + "trade_index": 1, + "payload": { + "order": { + "kind": "sell", + "status": "pending", + "amount": 0, + "fiat_code": "VES", + "min_amount": null, + "max_amount": null, + "fiat_amount": 100, + "payment_method": "face to face,bank transfer,mobile", + "premium": 1, + "created_at": 0 + } } } - } -} + }, + "", + ["", ""] +] ``` Let's explain some of the fields: diff --git a/src/take_sell_range_order.md b/src/take_sell_range_order.md index 3f8a47e..08d171d 100644 --- a/src/take_sell_range_order.md +++ b/src/take_sell_range_order.md @@ -22,7 +22,7 @@ If the order fiat amount is a range like `10-20` the buyer must indicate a fiat ## Mostro response -In order to continue the buyer needs to send a lightning network invoice to Mostro, in this case the amount of the order is `0`, so Mostro will need to calculate the amount of sats for this order, then Mostro will send back a message asking for a LN invoice indicating the correct amount of sats that the invoice should have, here the decrypted content of the message: +In order to continue the buyer needs to send a lightning network invoice to Mostro, Mostro calculates the amount of sats from the fiat amount the buyer selected, then sends back a message asking for a LN invoice indicating the correct amount of sats that the invoice should have, here the decrypted content of the message: ```json [ @@ -89,7 +89,7 @@ Mostro updates the addressable event with `d` tag `` to change the sta ## Using a lightning address -The buyer can use a [lightning address](https://github.com/andrerfneves/lightning-address) to receive funds and avoid to create and send lightning invoices on each trade, with a range order we set the fiat amount as the third element of the `payment_request` array, to acomplish this the buyer will send a message in a NIP-44 direct message (kind `14`) to Mostro with the following decrypted content: +The buyer can use a [lightning address](https://github.com/andrerfneves/lightning-address) to receive funds and avoid creating and sending lightning invoices on each trade, with a range order we set the fiat amount as the third element of the `payment_request` array, to accomplish this the buyer will send a message in a NIP-44 direct message (kind `14`) to Mostro with the following decrypted content: ```json [