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 Nodes

Swarms

Session requires a secondary logical data layer built on top of the Session Node Network to ensure reliable message storage and retrieval.

Swarms protect users from message loss if Session Nodes go offline, drop messages, or become otherwise unavailable. Messages are replicated across small groupings of Session Nodes (swarms). Swarm composition is determined by the network design, not individual nodes, keeping network swarms robust and operational even as Session Nodes join and leave the network.

The following set of simple rules ensure that Session Nodes within swarms remain synchronized as

the composition of swarms changes:

  • When a node joins a new swarm, existing swarm members recognize the new member and push the swarm’s data records to the new member.

  • When a node leaves a swarm, its existing records can be safely erased, with the exception of when the node is migrating from a dissolving swarm. In this case, the migrating node determines the swarms responsible for its records and distributes them accordingly.

Last updated 15 days ago