Ever feel like it's hard to keep up with technical developments in crypto? People ferociously @ each other on X, opining on infinitesimal details, while you just want to properly understand of the issue at hand? (er, rollup wars, hello)

I’m starting a content series aimed at the intermediate audience ✅🙍 - not pure beginner and not advanced yoda ❌👶🥷

Explain Again! is where no question is too stupid - as you’ll see from my stupid questions 😀 

On some episodes I interrogate expert friends, stubbornly digging until we get the fundamentals straight. On other episodes we’ll use visual explainers to grok complex dynamics.

We're kicking off Explain Again! with Session, the Signal-like chat app that is web3-native and privacy-first. 

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 Session whitepaper walkthrough: 

🔍 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.

Find out more about Session at getsession.org and x.com/session_app 

Follow for future episodes! Feedback and ideas for future episodes are welcome - DM me.

We're kicking off Explain Again! with Session, the Signal-like chat app that is web3-native and privacy-first. 

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.

https://www.youtube.com/watch?v=bgIitv3Dmkk