LogoLogo
DownloadsBlock ExplorerSupport
  • πŸ’‘Introduction to Oxen
  • πŸ“Downloads
  • πŸ†˜Support
  • About the Oxen blockchain
    • πŸ—ΊοΈOverview
    • πŸ“ŠToken economics
      • πŸ”₯Token burning
    • πŸ–₯️Oxen Service Nodes
    • πŸ’“Pulse: PoS on Oxen
      • 🀿Pulse: Deep dive
    • πŸ‘οΈBlink: Instant transactions
  • Using the Oxen Blockchain
    • πŸ“Overview
    • πŸ’°Oxen Wallet & Guides
      • Preparing for GUI Wallet setup (Windows)
      • GUI Wallet setup
      • GUI Wallet Quickstart
      • GUI Wallet Staking
      • Oxen Mobile Wallet Quickstart
      • Mobile Wallet Staking Guide
      • Exporting a CSV of your wallet transaction history
      • CLI Wallet setup (macOS)
      • Oxen Ledger Wallet setup: GUI Wallet
      • Oxen Ledger Wallet setup: CLI Wallet
      • CLI Wallet commands
      • Restoring an Oxen CLI Wallet from seed
      • Restoring an Oxen CLI Wallet from keys
    • πŸ–₯️Service Node guides
      • 🏎️Express service node setup guide
      • 🍺Full service node setup guide
      • πŸ’ΈStaking to a shared Oxen Service Node
      • πŸ›‘Service Node deregistration
      • πŸ› οΈService node tools and upkeep
    • ⛴️Migrating to the new Session Network
      • βœ…Migration Checklist
      • ❓Migration FAQ
      • πŸ”—Connecting to an Arbitrum One RPC Endpoint
      • πŸ”€How to set up an oxend L2 proxy
    • πŸ”‘Using Oxen Name System (ONS)
    • πŸ€“Advanced
      • Service node πŸ“ž RPC calls
      • Daemon πŸ“ž RPC calls
      • Wallet πŸ“ž RPC calls
  • Products built on Oxen
    • πŸ”’Session
      • πŸ“šGuides
        • 🐧Installing on Linux (Debian based distros)
        • πŸ—£οΈSession Open Group Server Setup
          • πŸ“—Read Only Room Setup
      • πŸ”€Oxen Name Service for Session
      • πŸ—οΈNetwork infrastructure
      • πŸ“¨Message routing
      • πŸ“ŽAttachments
    • 🌐Lokinet
      • πŸ“šGuides
        • 🐧Installing on Linux (CLI)
        • 🐧Installing on Linux (GUI)
        • 🐧Linux troubleshooting
        • 🍎Installing on macOS
        • πŸͺŸInstalling on Windows
        • 🍎macOS troubleshooting
        • πŸ“žRun a secure Mumble server over Lokinet
      • πŸ‘‹Exit nodes
      • πŸ§‘β€πŸ’»πŸ§‘πŸ’» SNApps
        • πŸš€Accessing SNApps
        • πŸ–₯️Hosting SNApps
        • πŸ—ΊοΈDomain Names For Lokinet (ONS)
        • ⏺️Configuring SRV Records
Powered by GitBook
On this page
  • Message routing
  • Asynchronous (offline) routing
  • Synchronous (online) routing

Was this helpful?

Edit on GitHub
Export as PDF
  1. Products built on Oxen
  2. Session

Message routing

PreviousNetwork infrastructureNextAttachments

Last updated 9 months ago

Was this helpful?

Message routing

Session follows one of two distinct cases for message routing, depending on the availability of participating clients:

Asynchronous (offline) routing

By default, or when either of the participating clients' statuses is determined as offline (see Synchronous Routing for how client status is determined), Session will use asynchronous routing. In asynchronous routing, the sender determines the recipient's swarm by obtaining the deterministic mapping between the recipient's long-term public key and the currently registered Oxen Service Nodes. This information is initially requested from a random service node by the sender and updated whenever the client gets an error message in the response that indicates a missing swarm.

Once this mapping is determined, the sender creates the message protobuf and packs the protobuf in an envelope with the information to be processed by service nodes: the long-term public key of the recipient, a timestamp, TTL ("time to live") and a nonce which proves the completion of the required proof of work. The sender then sends the envelope using an onion request to one or more random service nodes within the target swarm (in practice, each request is always sent to 3 service nodes to achieve a high degree of redundancy). These service nodes then propagate the message to the remaining nodes in the swarm, and each service node stores the message for the duration of its specified TTL.

Alice uses an onion request to communicate with three random service nodes in Bob’s swarm. Bob then uses an onion request to retrieve said message, by talking to three random service nodes in his swarm.

Synchronous (online) routing

Session clients include their online status in the encrypted protobuf of any asynchronous message they send. Along with their online status, a sending client also lists an Oxen Service Node in their swarm to which they are listening via onion request.

When a Session client receives a message which signals the online status of another client, the receiver sends an onion request to the sender's specified listening node. The recipient also exposes their own listening node to the sender. If this process is successful, both sender and receiver will have knowledge of each others' online status and corresponding listening nodes. Messages may now be sent synchronously through onion requests to the conversing clients' respective listening nodes.

Alice uses an onion request to send a message to Bob’s listening node. Bob receives this message using an onion request, then sends a message to Alice’s listening node.

Messages sent using this synchronous method do not contain proof of work, and listening nodes do not replicate or store messages. To ensure messages are not lost, receiving clients send acknowledgements after receipt of each message. If either device goes offline, this acknowledgement will not be received, and the client which is still online will fall back to using the above asynchronous method of message transmission.

Friend requests

Friend requests are sent the first time a client initiates communication with a new contact. Friend requests contain a short message with a written introduction, the sender's prekey bundle, and meta-information like the sender's display name and public key, which the recipient can use to respond. Friend requests are encrypted for the public key of the recipient using ECDH. When a friend request is received, the client can choose whether to accept it. Upon acceptance, the client can use the prekey bundle to begin a session and start sending messages asynchronously.

πŸ”’
πŸ“¨