Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 10 additions & 6 deletions src/add_bond_invoice.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,7 @@ Mostro sends a single `add-bond-invoice` message to the non-slashed counterparty
[
{
"order": {
"version": 1,
"version": 2,
"id": "<Order Id>",
"action": "add-bond-invoice",
"payload": {
Expand All @@ -35,6 +35,7 @@ Mostro sends a single `add-bond-invoice` message to the non-slashed counterparty
}
}
},
null,
null
]
```
Expand All @@ -58,13 +59,13 @@ 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 message whose 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
[
{
"order": {
"version": 1,
"version": 2,
"id": "<Order Id>",
"action": "add-bond-invoice",
"payload": {
Expand All @@ -75,7 +76,8 @@ The counterparty replies with a Gift wrap Nostr event whose rumor content carrie
}
}
},
"<index N signature of the sha256 hash of the serialized first element of content>"
"<index N signature of the sha256 hash of the serialized first element of content>",
["<identity pubkey>", "<identity signature>"]
]
```

Expand Down Expand Up @@ -111,7 +113,7 @@ Sent by Mostro to the counterparty immediately after successfully receiving and
[
{
"order": {
"version": 1,
"version": 2,
"id": "<Order Id>",
"action": "bond-invoice-accepted",
"payload": {
Expand All @@ -127,6 +129,7 @@ Sent by Mostro to the counterparty immediately after successfully receiving and
}
}
},
null,
null
]
```
Expand All @@ -141,7 +144,7 @@ Sent by Mostro to the counterparty when the Lightning payment to their invoice h
[
{
"order": {
"version": 1,
"version": 2,
"id": "<Order Id>",
"action": "bond-payout-completed",
"payload": {
Expand All @@ -157,6 +160,7 @@ Sent by Mostro to the counterparty when the Lightning payment to their invoice h
}
}
},
null,
null
]
```
Expand Down
9 changes: 6 additions & 3 deletions src/admin_add_solver.md
Original file line number Diff line number Diff line change
Expand Up @@ -32,13 +32,14 @@ The default remains `read-write` for backward compatibility.
[
{
"order": {
"version": 1,
"version": 2,
"action": "admin-add-solver",
"payload": {
"text_message": "npub1qqq884wtp2jn96lqhqlnarl4kk3rmvrc9z2nmrvqujx3m4l2ea5qd5d0fq"
}
}
},
null,
null
]
```
Expand All @@ -49,13 +50,14 @@ The default remains `read-write` for backward compatibility.
[
{
"order": {
"version": 1,
"version": 2,
"action": "admin-add-solver",
"payload": {
"text_message": "npub1qqq884wtp2jn96lqhqlnarl4kk3rmvrc9z2nmrvqujx3m4l2ea5qd5d0fq:read"
}
}
},
null,
null
]
```
Expand All @@ -68,11 +70,12 @@ Mostro sends this message to the admin:
[
{
"order": {
"version": 1,
"version": 2,
"action": "admin-add-solver",
"payload": null
}
},
null,
null
]
```
9 changes: 6 additions & 3 deletions src/admin_cancel_order.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,12 +6,13 @@ An admin can cancel an order, most of the time this is done when admin is solvin
[
{
"order": {
"version": 1,
"version": 2,
"id": "<Order Id>",
"action": "admin-cancel",
"payload": null
}
},
null,
null
]
```
Expand All @@ -24,7 +25,7 @@ When solving a dispute, the admin can optionally slash one or both parties' bond
[
{
"order": {
"version": 1,
"version": 2,
"id": "<Order Id>",
"action": "admin-cancel",
"payload": {
Expand All @@ -35,6 +36,7 @@ When solving a dispute, the admin can optionally slash one or both parties' bond
}
}
},
null,
null
]
```
Expand All @@ -61,12 +63,13 @@ Mostro will send this message to the both parties buyer/seller and to the admin:
[
{
"order": {
"version": 1,
"version": 2,
"id": "<Order Id>",
"action": "admin-canceled",
"payload": null
}
},
null,
null
]
```
Expand Down
9 changes: 6 additions & 3 deletions src/admin_settle_order.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,12 +6,13 @@ An admin can settle an order, most of the time this is done when admin is solvin
[
{
"order": {
"version": 1,
"version": 2,
"id": "<Order Id>",
"action": "admin-settle",
"payload": null
}
},
null,
null
]
```
Expand All @@ -24,7 +25,7 @@ When solving a dispute, the admin can optionally slash one or both parties' bond
[
{
"order": {
"version": 1,
"version": 2,
"id": "<Order Id>",
"action": "admin-settle",
"payload": {
Expand All @@ -35,6 +36,7 @@ When solving a dispute, the admin can optionally slash one or both parties' bond
}
}
},
null,
null
]
```
Expand All @@ -61,12 +63,13 @@ Mostro will send this message to the both parties buyer/seller and to the admin:
[
{
"order": {
"version": 1,
"version": 2,
"id": "<Order Id>",
"action": "admin-settled",
"payload": null
}
},
null,
null
]
```
Expand Down
3 changes: 2 additions & 1 deletion src/bond_slashed.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,7 @@ The `bond-slashed` action is a notification Mostro sends to a bonded party when
[
{
"order": {
"version": 1,
"version": 2,
"id": "<Order Id>",
"action": "bond-slashed",
"payload": {
Expand All @@ -34,6 +34,7 @@ The `bond-slashed` action is a notification Mostro sends to a bonded party when
}
}
},
null,
null
]
```
Expand Down
27 changes: 17 additions & 10 deletions src/cancel.md
Original file line number Diff line number Diff line change
@@ -1,35 +1,37 @@
# 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
[
{
"order": {
"version": 1,
"version": 2,
"id": "<Order Id>",
"action": "cancel",
"payload": null
}
},
"<index N signature of the sha256 hash of the serialized first element of content>"
"<index N signature of the sha256 hash of the serialized first element of content>",
["<identity pubkey>", "<identity signature>"]
]
```

## 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:

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Match the prose to the emitted action.

The text says cancel, but the example emits canceled. Keep those aligned so implementers don't key off the wrong action name.

Suggested fix
- Mostro will send a message with action `cancel` confirming the order was canceled, here an example of decrypted content of the message:
+ Mostro will send a message with action `canceled` confirming the order was canceled, here an example of decrypted content of the message:
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
Mostro will send a message with action `cancel` confirming the order was canceled, here an example of decrypted content of the message:
Mostro will send a message with action `canceled` confirming the order was canceled, here an example of decrypted content of the message:
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/cancel.md` at line 22, The prose in cancel documentation is inconsistent
with the emitted action name; update the wording in the cancel message example
so it matches the actual action used by Mostro. Align the text in src/cancel.md
with the action emitted by the cancellation flow, using the same naming as the
relevant cancel/canceled example to avoid ambiguity for implementers.


```json
[
{
"order": {
"version": 1,
"version": 2,
"id": "<Order Id>",
"action": "canceled",
"payload": null
}
},
null,
null
]
```
Expand Down Expand Up @@ -97,12 +99,13 @@ A user can cancel an `active` order, but will need the counterparty to agree, le
[
{
"order": {
"version": 1,
"version": 2,
"id": "<Order Id>",
"action": "cancel",
"payload": null
}
},
null,
null
]
```
Expand All @@ -113,12 +116,13 @@ Mostro will send this message to the seller:
[
{
"order": {
"version": 1,
"version": 2,
"id": "<Order Id>",
"action": "cooperative-cancel-initiated-by-you",
"payload": null
}
},
null,
null
]
```
Expand All @@ -129,12 +133,13 @@ And this message to the buyer:
[
{
"order": {
"version": 1,
"version": 2,
"id": "<Order Id>",
"action": "cooperative-cancel-initiated-by-peer",
"payload": null
}
},
null,
null
]
```
Expand All @@ -145,12 +150,13 @@ The buyer can accept the cooperative cancellation sending this message:
[
{
"order": {
"version": 1,
"version": 2,
"id": "<Order Id>",
"action": "cancel",
"payload": null
}
},
null,
null
]
```
Expand All @@ -161,12 +167,13 @@ And Mostro will send this message to both parties:
[
{
"order": {
"version": 1,
"version": 2,
"id": "<Order Id>",
"action": "cooperative-cancel-accepted",
"payload": null
}
},
null,
null
]
```
Expand Down
6 changes: 6 additions & 0 deletions src/chat.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,12 @@

To communicate directly, both the buyer and the seller do not use the current `Message` scheme explained [here](https://mostro.network/protocol/overview.html), as this communication excludes the Mostro daemon. To preserve user privacy, we use a simplified version of NIP-59 that allows us to hide the metadata of both parties from outside observers. However, this variant only contains a single event inside the wrapper. The inner event includes the sender’s trade pubkey and the corresponding signature to maintain the authenticity of the sender.

> **Scope note:** the [v1 → v2 transport migration](./transport_migration.md)
> applies only to messages exchanged **with the Mostro daemon**. This
> peer-to-peer chat never goes through the daemon, so it keeps the
> kind-`1059` scheme described below and is **not** affected by the
> v0.19.0 removal of the v1 transport.

## Shared Key

The messages between parties have a unique feature: instead of directing the events containing these messages to the counterparty’s trade pubkey, we direct them to a unique pubkey known only to both parties.
Expand Down
Loading