LogoLogo
Back to our website
  • Session Messenger
    • Installing Session
      • Installing on Linux (Debian based distros)
      • Installing Session using F-Droid
      • Installing Session using APKs
      • Installing beta versions of Session
    • Advanced Features
      • Communities
        • How to setup a Session Open Group Server (SOGS)
        • Creating a read-only channel using SOGS
      • Session Names and the Session Name Service (SNS)
        • Registering an Oxen Name using the Oxen Name Service
      • Session Pro
    • Contribute to Session Messenger
      • Development
      • Localization
  • Session Token (SESH)
    • Tokenomics
      • Genesis tokenomics
    • Rewards Programs
      • Service Node Bonus Program
      • Oxen Coin Claims
      • Testnet Incentive Program
    • Get Session Token (SESH)
      • How to create a crypto wallet
      • How to view SESH in your Wallet
      • How to use Session Token (SESH)
  • Session Network
    • Session Nodes
      • Staking and collateralization
      • Incentivization
      • Consensus
      • Swarms
      • Session Appchain
      • Deregistration
    • Session Protocol
      • Onion requests and message routing
      • Account IDs and self managed keys
      • Account restoration
    • Staking
      • Staking Reward Pool
  • Contribute to the Session Network
    • Frequently Asked Questions (FAQ)
    • Testnet
      • Staking to a Session Stagenet Multicontributor Node
      • Session Stagenet Node Setup
        • How to set up an oxend L2 proxy
  • Twitter / X
  • Discord
  • Session Token Website
  • Session Website
  • Session Whitepaper
Powered by GitBook
On this page
  1. Session Network
  2. Session Protocol

Onion requests and message routing

Session implements a simple onion-routing protocol, called Onion Requests, to protect user IP addresses.

Onion routing is a method of sending internet traffic (like messages) through multiple encrypted layers, like the layers of an onion. Each layer is ‘peeled’ by a different server in the network, hiding the sender's identity.

For the messaging context, this is critical for preventing a node or other party from using metadata to de-anonymize users or deduce conversation participants for a given chat.

Onion requests are a relatively simple system, built using TCP. Although this simplicity has its advantages, it also means that onion requests inherit some of TCP's limitations—such as slower connection speeds compared to other protocols.

To route a message, the sender first needs to find the Session Nodes in their recipient’s swarm. To do this, the client fetches the swarm mapping for their recipient’s Account ID. Given the swarm mapping, the sender creates a message and prepares the message to be sent to the Session Node network. The sender includes the necessary information for the message to be processed, including:

  • The Account ID of the recipient

  • The message timestamp

  • The message expiry time

  • The namespace where the message will be stored

The sender then sends this message—using an onion request—to a random Session Node within the recipient’s swarm. This Session Node will then propagate the message to the remaining nodes in the swarm, with each node storing the message until the specified expiry time.

By default, chat messages expire after two weeks. However, this can be configured using the Disappearing Messages feature in Session messenger

While functional, Onion Requests are a very limited message-based protocol built on top of TCP. Onion Requests are effective for passing messages across the network, but do not lend themselves well to expanding the network capabilities to large transfers or responsive voice/video communication.

In the future, it is intended that the Session client will be able to interface with the network’s more advanced onion-routing overlay network, making key features such as onion-routed voice and video calls possible.

Last updated 15 days ago