Introducing Explain Again!

Introducing a new series for people who want to dig deeper into technical developments in web3:

Explain Again!

It’s aimed at the intermediate audience ??? - not pure beginner and not advanced yoda ?????

The goal is to get past the walls of people @’ing each other with strong opinions on X.com, and instead arrive at a better understanding of the basic facts. No question is too stupid - as you will see from my stupid questions =D

Kicking off the first episode with a walkthrough of Session chat app's technical whitepaper

I kick off by scrutinizing Session’s technical white paper (getsession.org). Session is a slick chat app with a focus on user data ownership and metadata privacy. I interrogate Taylor Hornby, security engineer and early Zcasher.

We're kicking off Explain Again! with Session because they're pushing boundaries with their approach to privacy and distributed tech, complemented by a beautiful UI and smooth UX. I'm curious what tradeoffs they made and what the implications are for users.

Sneak peek of the topics covered:

?? Metadata Leakage: More Dangerous Than You Think

Even if message content is encrypted, knowing who is talking to whom, when, and how often can expose activists, dissidents, and high-value targets.

Session mitigates this by removing centralized servers from the equation and using onion routing—but with some key differences from Tor.

?? Like Tor, But Double Tor

Instead of a single onion route from sender to recipient, Session uses two separate onion circuits—one for sending and another for retrieving messages.

This prevents a single node from learning both ends of the conversation.

? Messages Expire if Not Received

Unlike traditional messaging apps, messages in Session are not stored indefinitely.

If a recipient doesn’t retrieve a message in time, it’s permanently lost—an interesting trade-off between privacy and usability.

?? The Tokenomics of Attacks

Running a node requires staking tokens, creating a financial cost for Sybil attacks.

But could attackers drive up token prices, making it prohibitively expensive for honest users to participate? The economic incentives remain an open question.

?? How Many Layers Should an Onion Have?

More hops in an onion route don’t always mean better security—timing correlation attacks can still deanonymize users.

Session sticks with the classic three-hop model, striking a balance between privacy and efficiency.

?? Forward Secrecy: A Notable Weakness

Unlike Signal, Session does not support forward secrecy—meaning if your key is compromised, past messages could be decrypted.

However, this is mitigated by ephemeral message storage (messages don’t persist forever).

?? Groups Over 100 Members? You’re On Your Own

Unlike Signal, large groups in Session require self-hosting—a departure from traditional privacy-focused messaging apps.

This forces users to take control of their own infrastructure but also raises questions about usability.

?? Session Name Service (SNS): A Double-Edged Sword

Human-readable account names are convenient, but they tie your pseudonymous identity to a recognizable handle, potentially weakening privacy.

Should you use one? It depends on your threat model.

Follow https://x.com/explainagain for future episodes.

Feedback and ideas for future topics are welcome.