n3xB Peer Messaging

See Architecture for where Peer Messaging fits in the overall n3xB protocol flow

n3xB standardizes how peer messaging can be conducted. Its is not mandatory for Trade Engines to use n3xB messaging schemes, but it is available. For n3xB Take Order Messages and Trade Response Messages, this is the assumed default.

Carrier

Until a more privacy preserving direct messaging method is widely available (see Privacy Improvement below), Nostr Encrypted Direct Messages NIP-04 is to be used to facilitate peer messaging.

To enhance robustness of peer messaging, clients should ensure that at least several of the relays listed by the counterparty's (NIP-65) Relay List Metadata is added as backup relays in the client's own relay list.

Push Notifications

Often times manual user actions, or a wake-up of a mobile client, is required to make sure the trade continues. Mobile push notification will be very valuable in these cases. As it is Nostr does not have any support for generating mobile push notifications. A NIP proposal have been made for mobile push here. This is not required to make n3xB possible, but it would be a huge improvement to the overall experience and usability if the capability is available. n3xB Peer Messaging shall adopt Nostr push notifications once available.

Pre-Defined Tags

Aside from the mandatory #p tag as specified in NIP-04. Tags are not used whatsoever, as they are in plain text and reduces secrecy and privacy for the trade and participants.

Identification

A n3xB Peer Message is identified by having the string "n3xB-peer-message" at the beginning of the content plaintext, before the JSON begins. By using a content header identifier instead of identification tags, privacy can be enhanced.

Content JSON

Note that this is the plaintext of what the decrypted content would be. The actual content that goes into a message would be encrypted as according to NIP-04.

{
  ...
  "content": {
    "type": "n3xB-peer-message"
    "peer_message_id": <32-bytes lowercase hex id of the Peer Message being responded to. Omit if n/a>
    "maker_order_note_id": <32-bytes lowercase hex id of the Maker Order Note this message corresponds to>
    "trade_uuid": <32-bytes lowercase hex Trade-UUID this message corresponds to>
    "message_type:" <message type, specifies whether its one of n3xB messages or a Trade Engine specific one>
    "message": {
      type: <message type identifier, specific to n3xB or a Trade Engine, as string>
      ... message specific JSON fields ...
    }
  ...
}

Message Types

If a Trade Engine chooses to use the n3xB Peer Messaging scheme, it can define its own Message Types and Message JSON formats. The following are Message Type string codes defined by n3xB, and a link to the corresponding specification of the Message JSON format itself.

`message_type` string code	Message specification
n3xB-taker-offer	Take Order Message
n3xB-trade-response	Trade Response Message

Proof of Work

Proof of Work should be generated as according to NIP-13. The difficulty for all messages pertaining to a particular Maker Order Note needs to meet the minimum specified in the pow_difficulty field. Otherwise all parties involved has the right to not respond to any peer messages pertaining to that Order.

Privacy Improvement

NIP-24 Private, Encrypted Direct Messaging is also a work in progress to make Nostr direct messaging more anonymous. However if push notification is to be employed by relays, there is no way to obfuscate who the actual recipient is. This might be a privacy trade-off that a client implementation must make when NIP-24 actually becomes available.

4.3 KiB Raw Permalink Blame History