konstruktDM
Member
- Messages
- 4
- Reaction score
- 0
- Points
- 1
Hello everyone. I'd like to discuss a messenger few people know about, although its architecture provides a level of anonymity unattainable by most popular apps — including those considered "secure."
This is a problem that even good messengers fail to solve:
Signal encrypts message contents with end-to-end encryption — which is great. But the Signal server still knows who is communicating with whom, when, and how often — the metadata remains visible, even if the message text is unreadable. Session and similar messengers without a phone number solve part of this problem by routing through their own network of nodes, but there is still infrastructure — servers, nodes — through which traffic passes.
Ricochet Refresh goes further than all others — it removes the server from the equation entirely.
Its architecture is P2P over Tor, without a single server.
Instead of sending a message through an intermediate infrastructure, Ricochet establishes a direct connection between the two parties via the Tor hidden service. Each Ricochet user is their own "server" in the form of an onion address — messages travel directly from one onion address to another, bypassing any third party.
This is a fundamentally different approach than any messenger with a central server. There's no company that can provide logs. There's no database with metadata about who communicated with whom. There's no physical location where you can file a legal request, because there's nothing to seize — correspondence isn't stored anywhere except on the devices of the users themselves.
How this works in practice:
When installed, Ricochet generates a unique onion address, which is your "identifier" — not a phone number, email, or nickname linked to the server, but simply a cryptographically generated address.
To add a contact, you exchange this onion address using any method (in person or through another secure channel) — adding them to your contacts. Then, when sending a message, the app directly contacts the contact's onion address via Tor. If the recipient is offline, the message isn't delivered at all because there's no server to hold it in a queue until the recipient comes online.
What does this mean for metadata specifically?
With traditional messengers, even with full encryption, the server sees the IP addresses of connections (or at least the fact of connection), the active time, the frequency of messages between specific pairs of users, and the size of the transferred data. From this set of metadata, with proper analysis, it's possible to reconstruct a social graph — who is communicating with whom — even without reading a single message.
With Ricochet, there's no physical place for metadata to accumulate. The connection exists precisely at the moment the message is transmitted, directly between two onion addresses via Tor, and disappears immediately afterward. There's no intermediate node that can see both ends of the conversation simultaneously.
The reason this works is because of the Tor hidden services architecture.
Each onion address is routed through the Tor network so that no node along the way knows both the sender and the recipient simultaneously — this is a built-in property of the Tor protocol, on which Ricochet is built. The app doesn't add anonymity on top of the regular network — it uses the anonymity provided by Tor's architecture for direct P2P connections instead of the traditional client-server model.
Fair restrictions — this isn't a messenger for everyday use.
Both parties must be online simultaneously for a message to be delivered — there's no cloud-based message queue, like in Telegram or WhatsApp, where you can write something and the recipient will read it later when they turn on their phone.
There's no synchronization between devices — the entire identifier (onion address and keys) resides on the single device where Ricochet is installed. Lose your device — lose your identifier, and you start over with a new address and exchange it with all your contacts.
There are no group chats in the classic sense — the architecture is tailored specifically for private, one-on-one conversations, not for coordinating large groups.
It requires both parties to be technically prepared to keep the app running at all times to receive messages — this is inconvenient for the casual user, but for those who truly value maximum anonymity for a specific conversation, it's a conscious compromise.
For whom does this really make sense?
Not for everyday messaging with friends — Signal or Session are more convenient and sufficient for that. Ricochet makes sense specifically for conversations where the guarantee of metadata absence is more important than convenience — one-off sensitive discussions, coordination between people who require an architectural impossibility of linking their conversations post-factum.
Bottom line:
Ricochet Refresh doesn't try to be a messenger for everyone — it's a highly specialized tool for a specific task: a conversation whose existence should be private to no one but the two parties. This comes at the cost of convenience — no offline delivery, no synchronization, no groups. But for those rare cases where it's truly necessary, there's simply nothing stronger in terms of anonymity architecture among messengers.
This is a problem that even good messengers fail to solve:
Signal encrypts message contents with end-to-end encryption — which is great. But the Signal server still knows who is communicating with whom, when, and how often — the metadata remains visible, even if the message text is unreadable. Session and similar messengers without a phone number solve part of this problem by routing through their own network of nodes, but there is still infrastructure — servers, nodes — through which traffic passes.
Ricochet Refresh goes further than all others — it removes the server from the equation entirely.
Its architecture is P2P over Tor, without a single server.
Instead of sending a message through an intermediate infrastructure, Ricochet establishes a direct connection between the two parties via the Tor hidden service. Each Ricochet user is their own "server" in the form of an onion address — messages travel directly from one onion address to another, bypassing any third party.
This is a fundamentally different approach than any messenger with a central server. There's no company that can provide logs. There's no database with metadata about who communicated with whom. There's no physical location where you can file a legal request, because there's nothing to seize — correspondence isn't stored anywhere except on the devices of the users themselves.
How this works in practice:
When installed, Ricochet generates a unique onion address, which is your "identifier" — not a phone number, email, or nickname linked to the server, but simply a cryptographically generated address.
To add a contact, you exchange this onion address using any method (in person or through another secure channel) — adding them to your contacts. Then, when sending a message, the app directly contacts the contact's onion address via Tor. If the recipient is offline, the message isn't delivered at all because there's no server to hold it in a queue until the recipient comes online.
What does this mean for metadata specifically?
With traditional messengers, even with full encryption, the server sees the IP addresses of connections (or at least the fact of connection), the active time, the frequency of messages between specific pairs of users, and the size of the transferred data. From this set of metadata, with proper analysis, it's possible to reconstruct a social graph — who is communicating with whom — even without reading a single message.
With Ricochet, there's no physical place for metadata to accumulate. The connection exists precisely at the moment the message is transmitted, directly between two onion addresses via Tor, and disappears immediately afterward. There's no intermediate node that can see both ends of the conversation simultaneously.
The reason this works is because of the Tor hidden services architecture.
Each onion address is routed through the Tor network so that no node along the way knows both the sender and the recipient simultaneously — this is a built-in property of the Tor protocol, on which Ricochet is built. The app doesn't add anonymity on top of the regular network — it uses the anonymity provided by Tor's architecture for direct P2P connections instead of the traditional client-server model.
Fair restrictions — this isn't a messenger for everyday use.
Both parties must be online simultaneously for a message to be delivered — there's no cloud-based message queue, like in Telegram or WhatsApp, where you can write something and the recipient will read it later when they turn on their phone.
There's no synchronization between devices — the entire identifier (onion address and keys) resides on the single device where Ricochet is installed. Lose your device — lose your identifier, and you start over with a new address and exchange it with all your contacts.
There are no group chats in the classic sense — the architecture is tailored specifically for private, one-on-one conversations, not for coordinating large groups.
It requires both parties to be technically prepared to keep the app running at all times to receive messages — this is inconvenient for the casual user, but for those who truly value maximum anonymity for a specific conversation, it's a conscious compromise.
For whom does this really make sense?
Not for everyday messaging with friends — Signal or Session are more convenient and sufficient for that. Ricochet makes sense specifically for conversations where the guarantee of metadata absence is more important than convenience — one-off sensitive discussions, coordination between people who require an architectural impossibility of linking their conversations post-factum.
Bottom line:
Ricochet Refresh doesn't try to be a messenger for everyone — it's a highly specialized tool for a specific task: a conversation whose existence should be private to no one but the two parties. This comes at the cost of convenience — no offline delivery, no synchronization, no groups. But for those rare cases where it's truly necessary, there's simply nothing stronger in terms of anonymity architecture among messengers.
