Smaller nodes, stronger encryption: Oxen 11.7, Storage Server 2.12 and Session Router 1.1

Coordinated updates are now available for three of the pieces of software that make up a Session Node: oxend 11.7.0, Storage Server 2.12.0 and Session Router 1.1.0. Together they make Session Nodes considerably lighter on disk, memory and CPU, make message storage across the network more dependable and bring forward-secret, post-quantum encryption to Session Router, the onion routing layer future versions of Session will use to talk to the network.

The short version for node operators

• Upgrading is optional for now, but recommended. The three updates go together: oxend 11.7.0 requires Storage Server 2.12.0 and Session Router 1.1.0, and stops sending uptime proofs if either is older. If you use the Session Debian/Ubuntu packages, a normal apt upgrade updates all three at once.

• Nothing needs to change in your setup. No new ports, no config changes, no required resync. Expect the first start after upgrading to take a little longer than usual while some database tables are updated. Existing nodes keep their current blockchain database; moving to the new storage format described below is optional.

• Want a much smaller node? oxend can now run as a "light node" that needs about 1.4GB of disk instead of roughly 20GB. This is opt-in; see below.

• Debian 11 ("bullseye") and Ubuntu 20.04 ("focal") are no longer supported. Both have reached end of life and no longer get security updates. Packages are now built for Debian 12+ and Ubuntu 22.04+.

oxend 11.7: a Session Node in under 2GB

Until now, every Session Node has had to keep a full copy of the Oxen blockchain, which today takes around 20GB and slowly grows. Almost all of that history is irrelevant to what a Session Node actually does day to day: validating new blocks, taking part in quorums and keeping the Session Node list and rewards up to date.

oxend 11.7.0 adds a new storage engine built on SQLite. It keeps the blockchain and all of oxend's other data in a single database file, updated together, in place of the previous mix of LMDB and separate SQLite files. On its own, that makes a full node a little smaller (about 16GB). More importantly, it makes the new light node mode possible: a node can keep only a recent window of block history, such as the last two weeks, and drop everything older. A light node still fully validates the chain, participates in quorums and earns rewards exactly as a full node does, but needs about 1.4GB of disk.

Light nodes and full nodes work side by side on the network: each node tells its peers how much history it keeps, and syncing nodes pick peers that have the blocks they need. Existing nodes keep running on their current database after upgrading. Switching to a light node is optional; the Oxen 11.7.0 release notes explain how.

This release also lowers oxend's memory use. Historical Session Node data that used to sit in memory permanently is now stored compressed on disk and loaded only when needed, cutting a typical node's memory use by about 100MB.

Full details: Oxen 11.7.0 release notes

Storage Server 2.12: keeping swarms in step

Session messages are stored on a small group of Session Nodes called a swarm, and every node in the swarm keeps a copy, so a message stays available even if some of those nodes go offline. That only works if the nodes in a swarm actually stay in sync with each other. Storage Server 2.12.0 reworks how they do that.

• Nodes now talk to each other over QUIC, the same modern transport Session clients already use to reach storage servers. Each connection between two nodes keeps large background transfers separate from live message traffic, so a busy swarm sync no longer slows down delivery of new messages.

• Messages that fail to reach another swarm member are retried instead of being dropped, and those retries survive a restart.

• New swarm members get caught up reliably. When a node joins a swarm, the existing members send it their messages in small, acknowledged batches, and an interrupted transfer picks up where it left off instead of starting over.

• Less wasted work. Analysis of live mainnet nodes showed that most database writes were clients repeatedly refreshing the expiry of the same messages. Those refreshes now take far less work, and fetching messages no longer re-sorts an account's messages on every poll, so storage servers read from and write to disk much less. A database lock that, under heavy load, could leave writes waiting indefinitely has also been removed.

The release also fixes a handful of crashes and hangs, including a deadlock that could cause the storage server to stall until it was automatically restarted. All of this works alongside nodes still running 2.11, so the network doesn't need to upgrade all at once.

Full details: Storage Server 2.12.0 release notes

Session Router 1.1: post-quantum sessions

Session Router is the onion routing network that will become the foundation for how Session apps communicate. It launched last year alongside oxend 11.6, and has been running on a growing share of Session Nodes since.

The headline change in 1.1.0 is a new encryption handshake for Session Router sessions:

• Forward secrecy. Every session now uses fresh, temporary keys on both sides. Even if a node's long-term keys were compromised later, past sessions could not be decrypted with them.

• Post-quantum protection. The handshake also includes ML-KEM-768, a key exchange standardized by NIST to resist attacks by future quantum computers. This guards against "harvest now, decrypt later" attacks, where someone records encrypted traffic today in the hope of breaking it years from now.

• No extra delay. The new handshake adds no extra round trips, so connections become usable just as quickly as before.

Session Router 1.1.0 also reduces the processing relays need to do to build onion paths, cuts memory use per connection by more than half, and fixes a bug that had relays repeatedly re-sending the entire network's relay list to clients that already had it. For clients, it fixes cases where a device could lose track of the network after a connectivity drop and never recover without a restart, and makes it much faster to skip over relays that can't be reached.

As with Storage Server, 1.1.0 is fully compatible with 1.0 relays and clients: the new handshake and path formats are used wherever both sides support them. Once 1.1.0 is required across the network, the old handshake will be retired.

Full details: Session Router 1.1.0 release notes

What's next

This release doesn't include a mainnet hard fork, but the next one is already running on testnet. Among other changes, it increases the size of the pulse quorums that produce Oxen blocks, from 11 to 25 nodes. It will be scheduled for mainnet in a future mandatory update.

A few additions to Storage Server are also in progress, designed to let future Session clients query quorums more effectively. The aim is to include these before the upgrade becomes mandatory.

Upgrading

Session Node operators on Debian 12+ or Ubuntu 22.04+ can upgrade from the APT repository at deb.session.foundation:

1. First, sync your repositories:

   sudo apt update

2. Then install updates using:

   sudo apt upgrade

Static binaries for other systems are available on each project's release page.

Operators still running Debian 11 or Ubuntu 20.04 won't receive these updates from the APT repository. They will need to upgrade their server to a supported distribution release first (Debian 12 or 13, or Ubuntu 22.04 or 24.04), and then upgrade the Session Node packages.

The full, operator-focused release notes have all the details:

• Oxen 11.7.0

• Storage Server 2.12.0

• Session Router 1.1.0

Many thanks to all the operators who have been running Session Router and testnet nodes and reporting issues.