degenrocket / degenrocket is on Nostr

Being a long-time user of Session and SimpleX, I never had a chance to write down a proper review of both architectures, despite being asked to do so. Well, the time has come.
This multi-signed message will be pushed to Spasm and Nostr networks, so you can reply with Ethereum and Nostr private keys. I haven't added editing to Spasm yet and Nostr notes cannot be edited by design, so any edit/update will be added as a comment to this post.
I've just finished watching an interesting interview with Session CTO KeeJef hosted by ShadowRebel from SimplifiedPrivacy. I'd highly recommend to check it out if you can handle very poor audio quality and disrupting video. It's still not a proper Session vs SimpleX debate, but ShadowRebel did a pretty good job asking many important questions about Session's architecture, unlike many other privacy soy boys.
https://simplifiedprivacy.com/interview-session-messenger/keejef-vs-simplex.html
I've also recently approached many famous privacy influencers trying to onboard them to Spasm and I've been surprised by a few things:
- the majority of them have not yet transitioned to web3,
- literally nobody lists Session in the contacts section,
- many have started using SimpleX.
I'll keep my disappointment about the lack of web3 adoption among privacy people for another rant, but I'd like to address Session vs SimpleX situation. Generally, I felt great that I can finally chat with many of them via SimpleX because I haven't used Matrix or Signal due to privacy concerns.
However, after talking with a few tech-savvy people about SimpleX and Session, I quickly realized that most of them don't understand architectures of these two different solutions, but they usually have a strong opinion that Session is garbage, while SimpleX is private, decentralized, has no IDs, hides metadata, etc.
Basically, a typical bitcoin maxi mindset that now expanded to SimpleX, forming a BLNS (Bitcoin LN Nostr SimpleX) tech cult with people like Jack Dorsey backing all of them.
Since I'm not a cryptographer, in this post we will focus on architectures and PR strategies of these two different messaging apps, assuming that neither of them is a backdoored honeypot.
## Session
Let's start with Session, focusing on PFS, usernames, metadata, and decentralization.
### PFS
One of the major well-known Session drawbacks is lack of perfect-forward secrecy (PFS), which was disabled because users were falling out of sync due to complexity of multi-device syncing in a decentralized system. KeeJef argues that it's not a big deal since scrapping encrypted messages from the network is very difficult, so the most realistic attack vector here requires a full access to a device, which is game over regardless whether PFS is enabled or not.
His argument makes sense only if the network is indeed sufficiently decentralized. According to KeeJef, there are currently around 320 Session swarms, but we don't know how many of them are controlled by an adversary. Additionally, all databases leak at some point, so an adversary can collect that data through other means and decrypt it later after obtaining user's encryption keys in accordance with the "harvest now, decrypt later" strategy.
Session swarms are not required to store messages beyond a certain amount of time, but we cannot enforce deletion of these messages and there were multiple reports about receiving very old messages after restoring accounts via seed phrases despite enabling disappearing messages.
Basically, he is clearly downplaying absence of forward secrecy.
Besides, critics argue that PFS can be enabled even with Session's design.
https://soatok.blog/2025/01/20/session-round-2/
### Usernames
During the interview, ShadowRebel has pointed out one of the most undervalued features of the Session architecture, which is an ability to have uncensorable communication channels with your audience by utilizing usernames (ONS).
Let me explain for people who don't use Session. You can buy a username like `degenrocket` with your Oxen private key and assign it to your Session ID so people can find you by simply typing `degenrocket` into the app.
This setup is very different from most other blockchain-based naming systems like Ethereum Name Service (ENS) because if an adversary gets access to your Ethereum private key, he can steal all your NFTs, including ENS usernames. That won't work with Session's ONS because you'll be able to re-assign your username to a different Session ID with your Oxen private key, assuming that the latter didn't leak.
For example, SimplifiedPrivacy created a Session bot which mimics functionality of Telegram channels. You can try it out by sending a message to `simple`. If an adversary will get access to a server from which the bot operates, SimplifiedPrivacy will redeploy the bot to a new server and re-assign the username to a new Session ID.
There is no other ecosystem that provides similar functionality. Yeah, you can create an onion site, but if your server is seized or your hidden service private key is compromised, you will have to generate another onion address and relay that information to users.
However, Oxen Name System (ONS) will soon transition to Arbitrum-based Session Name System (SNS) and it seems like Session CTO himself doesn't fully know what exactly gonna happen with old ONS usernames.
### Metadata
Session's metadata protection involves built-in onion routing within its network, which requires time-locking OXEN coins to run a service node.
In theory, that should significantly increase costs of attacking the network by running many nodes and correlating traffic. However, with OXEN sitting at just $6 million market cap the cost of such an attack is not very high for a well-funded adversary. Besides, OXEN doesn't have any liquidity because it has been delisted from all centralized exchanges, so buying OXEN tokens for such an attack will be done OTC, which won't significantly increase the price of a token.
That said, Session has been transitioning to a transparent Ethereum-based ERC-20 token called SESH for over 1.5 years, so the economics of Session might change very soon.
https://getsession.org/blog/upgrading-to-session-network
It's also worth mentioning that onion routing only hides some metadata like ID addresses and internet speed/ping, but it doesn't protect from other metadata analyses like correlations based on timestamps. To fight time-based analysis you have to introduce random and large delays on the app level and use mixnets like Nym.
### Decentralization
Session node operators are incentivized with tokens for running infrastructure, which increases decentralization, but the team failed to create strong demand for OXEN coin and it's unclear whether they will be able to increase buying pressure for the new SESH token.
And there are a few centralization issues that haven't been solved yet.
- Unlike text messages, files are currently sent via a centralized server. Although, each file is still encrypted and 3-hop onion routing still applies. There are plans to add an ability to specify a custom file server in the future.
- The app uses centralized seed nodes to discover other nodes upon the first start up, which is a common problem of most decentralized networks. There are plans to hardcode a list of decentralized nodes into each app release to partially mitigate that issue, but this approach has its own downsides like making it easier for censors to block IP addresses of these nodes.
- Public chats with over 100 members (SOGS) are hosted on centralized servers, which can be seized.
Unfortunately, ShadowRebel didn't ask KeeJef about all the drama with the transition to SESH and how the Session team treated its community, but I'd assume that there were time constrains.
## SimpleX
Now let's look at SimpleX since it was mentioned multiple times during the interview and SimpleX's CEO Evgeny Poberezkin likes to criticize Session in his interviews/articles without providing much details.
Note that SimpleX Chat is built on top of the SimpleX platform/network, but I'll refer to it as "SimpleX" for simplicity.
By the way, this post will have a lot of criticism of SimpleX, so if you think that I'm a Session shill, then be sure that I also criticize many things that they do and I even proposed a community fork back in 2023 after they decided to ditch its privacy coin in favor of ERC-20 token despite backlash from the community.
https://github.com/oxen-io/oxen-improvement-proposals/issues/38
In fact, I use both Session and SimpleX for different purposes because I understand limitations of each solution.
So, my biggest issue with SimpleX is not even its architecture, but rather constant manipulation that creates a false impression about the amount of privacy it actually provides. Let's look at a few examples.
### IDs
> SimpleX - the first messaging platform that has no user identifiers of any kind - 100% private by design!
> Other apps have user IDs: Signal, Matrix, Session, Briar, Jami, Cwtch, etc. SimpleX does not, not even random numbers.
SimpleX claims that there are no IDs and that SimpleX servers know nothing about their users. SimpleX's CEO repeats that in every interview hosted by various "privacy" youtubers like WatchmanPrivacy, who always give him softball questions, one after another, which eventually misleads users into believing in some quantum magic.
In reality, there is a message queue identifier (ID) for each contact/chat, which can be used instead of an account ID to correlate metadata and spy on users.
Occasionally rotating these IDs doesn't do much since they can be correlated as well, especially in the age of AI-powered analytics. I'd imagine that rotating the queue ID after every message would be interesting, but that would probably require a centralized infrastructure to make sure that users don't fall out of sync as it was happening with Session users before they disabled PFS.
Here is a direct quote from SimpleX blog:
> To deliver mesages, instead of user IDs used by all other platforms, SimpleX has identifiers for message queues, separate for each of your contacts.
These message queue IDs can be clustered together into user's connection graph with very high probability through AI-powered metadata analysis and assigned an account ID similar to the concept of shadow accounts on Facebook. There might be different methods to do that, but the most simple one is to cluster request batches. That can be combined with traditional traffic analysis attacks to deanonymize users and their contacts.
Let's dumb it down. The whole idea of using pairwise per-queue identifiers and pairwise pseudonymous identifiers (PPIDs) in general is to prevent an adversary from correlating them by simply comparing these IDs. However, an adversary can easily correlate them using other methods through metadata analysis. For example, any simple analytics tool will be able to cluster together different PPIDs coming from the same IP address around the same time.
> With SimpleX there is no meta-data in common between your conversations with different contacts - the quality that no other messaging platform has.
That is simply not true. For example, when you go online your SimpleX app will check for new messages from different contacts by sending multiple requests with IDs (PPIDs) of different message queues to a server. These requests will share the same metadata like IP address and timestamp, which is enough to cluster them together. Repeat that a few times throughout the day and that would be enough for an adversary to send a drone your way, especially if you don't use Tor to mask your real IP address.
In fact, that probabilistic guess can even be used in courts in many hostile jurisdictions. For example, check out Bitcoin Fog case where Chainalysis used its black box clustering methodology that hasn't even been properly peer-reviewed and the judge stated that it was "sufficiently reliable" because "90 percent" or "80 percent" probability is good enough. Roman Sterlingov was sentenced to 12.5 years. #FreeRoman
https://www.therage.co/bitcoin-fog-sentencing/
There are some mitigation strategies that include frequent rotation of these IDs, data poisoning via random requests to unused old message queues, de-syncing of requests with random and large delays or even disabling auto-updates, using different receiving servers for each chat, and using stream isolation to assign a different Tor exit node for each chat, but all of them won't provide a bulletproof protection against sophisticated analytics tools and they will significantly reduce UX, meaning that these features will be strictly opt-in and won't be used by regular users.
And I didn't even mention that a server can log estimated internet speed and ping of each request sender, especially when there are many messages in a queue.
Lastly, the most important part of these mitigation strategies is that they have to be actually implemented before we can say that SimpleX is "100% private by design".
But what about the audit conducted by Trail of Bits?
https://github.com/simplex-chat/simplex-chat/blob/stable/docs/SimpleX_Design_Review_2024_Summary_Report_12_08_2024.pdf
They pointed out a few correlation attacks related to a transport layer, but they completely ignored correlation attacks based on collected metadata by SimpleX servers. I wouldn't suggest any conspiracy, so I'd assume that it was outside the scope of the audit, which itself is very surprising and should raise a few eyebrows.
Actually, if you are a journalist or a podcaster reading this, then you should definitely ask Evgevy why did the audit completely ignore all deanonymization attacks performed by SimpleX servers. I'm sure that Trail of Bits has enough expertise and resources to find much more vulnerabilities and attack vectors there than I can.
I'd also suggest to conduct additional audits, including by non-US-based companies.
But wait... didn't SimpleX implement a robust metadata protection in June 2024, prior to the audit?
https://simplex.chat/blog/20240604-simplex-chat-v5.8-private-message-routing-chat-themes.html
Well, let's take a look at it.
### Metadata
> Private message routing is, effectively, a 2-hop onion routing protocol inspired by Tor design, but with one important difference - the first (forwarding) relay is always chosen by message sender and the second (destination) - by the message recipient. In this way, neither side of the conversation can observe IP address or transport session of another.
I'd highly recommend to read this post because the level of manipulation there is truly astonishing.
This is not a metadata protection. This does not protect users from metadata collection by SimpleX servers. However, SimpleX mentions it in many articles, FAQ, and it's being repeated by many SimpleX fans. I'd emphasize again that the majority of SimpleX users use default servers and this "private message routing" does nothing to protect their metadata from server operators. Moreover, the article was published long before Flux integration (more on that later).
It's literally the most basic expectation in any other non-p2p messaging app that a person you're chatting with can't see your ID address. However, that's not the case with SimpleX because an adversary can easily collect your IP address in any private or public chat.
The "private message routing" is simply a fix to an obvious design flaw that doesn't even exist in any other non-p2p messaging app. In other words, this attack vector existed only in SimpleX due to its unique architecture, the team eventually tried to patch it with a questionable solution, and then presented it almost as a bulletproof metadata protection.
Wait... can we then say that all other messaging apps also have metadata protection since they never had that vulnerability to begin with?
You can argue that the SimpleX team doesn't officially call it a full "metadata protection" and you'll be right, but they are using it in exactly that context and they are very well aware that most SimpleX fans think that SimpleX has metadata protection.
https://simplex.chat/faq/index.html#does-simplex-protect-my-ip-address
> Does SimpleX protect my IP address?
> Yes! SimpleX Chat from version 6.0 uses private message routing whenever you send messages to unknown servers (all servers in app network settings, both enabled and not, are considered "known").
Here is another example that presents "private message routing" as a much better alternative to onion routing in Tor and Session.
> SimpleX network has private message routing (2-hop onion routing) — it prevents server operators from discovering who connects to whom via network traffic metadata. Onion routing used in Tor-based messengers and in Session also hides it. But because neither Tor nor Session users have knowledge about who operates servers, in some cases the clients may connect via the servers controlled by one entity, that may learn the IP addresses of both parties.
Technically, it's absolutely true that a well-funded adversary can run many Tor or Session nodes to correlate the traffic, especially since running Tor nodes doesn't require staking any tokens and market cap of Session's OXEN token is much lower than market cap of any third-tier memecoin like HarryPotterObamaSonic10Inu(ETH).
However, it's kinda funny to hear that from SimpleX, which itself relies on a heavily centralized network without any real metadata protection. Note how they mention "private message routing" in the same paragraph, which intentionally misleads readers into thinking that this "2-hop onion routing" somehow protects users from metadata collection by SimpleX servers and completely replaces the need for a proper decentralized network.
Let's dumb it down.
- The purpose of 3-hop onion routing in Tor and Oxen/Session networks is to hide your IP address from a server when both fetching or sending new messages.
- In SimpleX's current design even with "private message routing" enabled you fetch messages directly from a server, so it can log your IP address and potentially other metadata, such as approximate internet speed and ping.
Basically, comparing apples to oranges is very misleading.
> Private message routing is, effectively, a two-hop onion packet routing.
No, it's not.
Misrepresenting a one-hop onion routing as a two-hop onion routing is another deliberate manipulation.
Common practice is to count the amount of hops (relays) between a user and a destination server. Thus, SimpleX has only one hop of onion routing, not two. If you really insist on calling SimpleX's routing a "2-hop onion routing", then you should also call Tor's and Session's routing a "4-hop onion routing".
In other words, it's either 1 vs 3 hops or 2 vs 4 hops. In any case, SimpleX has two hops less.
Now if we count the amount of hops between two users, the difference becomes even larger.
`SimpleX: Alice - 1 relay - server - Bob`
`Session: Alice - 3 relays - swarm - 3 relays - Bob`
Depending on your counting method, it's either 1 vs 6 hops or 2 vs 7 hops. Basically, five hops less.
https://docs.oxen.io/oxen-docs/products-built-on-oxen/session/message-routing
However, SimpleX thinks that their routing is better at preventing server operators from discovering who connects to whom.
> SimpleX network has private message routing (2-hop onion routing) — it prevents server operators from discovering who connects to whom via network traffic metadata.
That said, SimpleX has an interesting implementation of this private message routing, so it would be great to have an independent audit of the feature. And I'm curious why this feature wasn't included in the Trail of Bits audit since it was released before the audit and SimpleX seems to have enough funding.
https://simplex.chat/faq/index.html#doesnt-private-message-routing-reinvent-tor
...
It's also important to note that this "private message routing" is enabled by default even though it has serious drawbacks in certain scenarios. For example, you want to send your tech-savvy friend a message via SimpleX. Without this "private message routing" you will send a message directly to a receiving server of your friend. However, since "private message routing" is enabled by default, you introduce a third party that can collect your metadata and discover the IP address of your friend's server.
That said, I'd like to mention that SimpleX's design has its use-cases because a tech-savvy user can choose his own server, which is not the case with Session. I have a friend who prefers SimpleX over Session because he runs his own SimpleX server, but that has certain trade-offs. For example, everybody can see his custom receiving server address, so he cannot have different identities in different private and public chats.
Essentially, SimpleX's dilemma can be roughly summed up in a single sentence: you're forced to choose between relying on someone else's servers and trusting they won't compromise your privacy, or running your own server, which limits you to a single identity since your server's address becomes synonymous with your identity.
I'm literally having flashbacks into LN debates right now.
### Decentralization
OK, this manipulation is really funny. In the following article SimpleX proudly marks itself as the only "fully decentralized" messaging app after adding just one alternative opt-in centralized server operator controlled by one company as a proof-of-concept test flight. I kid you not. Literally! You can read the article from November 2024 and then go listen to Evgeny's OptOut interview two months later starting from 13:30, it's hilarious.
https://simplex.chat/blog/20241125-servers-operated-by-flux-true-privacy-and-decentralization-for-all-users.html
https://optoutpod.com/episodes/improving-simplex/
I want to clarify that there is nothing wrong with testing centralized services, but may be it's a bit too early to call yourself an only "fully decentralized" messaging app yet.
### KYCed operators
Interestingly, in the same post SimpleX advocates for the use of fully compliant infrastructure.
> You may argue that when the operators are known, the servers data can be requested by the authorities. But such requests, in particular when multiple operators are used by all users, will follow a due legal process, and will not result in compromising the privacy of all users.
Let me translate that into English: your privacy will be compromised only if you talk about something actually important.
When did cypherpunks become obedient slaves? What's next? Adding KYCed payment methods? TBH, I wouldn't be even surprised since that would be fully aligned with bitcoin maxi's journey from "not your keys, not your coins" to zapping on Damus.
It's important to mention here that while the Session network is very different because most node operators are not known to the public, both SimpleX and Session teams are very similar when it comes to compliance because they are fully doxxed and based in very hostile jurisdictions. In fact, Session is rapidly moving towards even more compliance with its transparent SESH token and freemium model with KYCed payment methods through centralized app stores.
Unfortunately, the vast majority of projects have already compromised on this front, but a few still uphold cypherpunk values. I'm curious to see the future development of DarkFi super app and its DarkIRC chat addon.
https://dark.fi/insights/darkfi-app-alpha-release.html
That said, I agree with SimpleX's article that Matrix is shit and I never understood why so-called "privacy" influencers liked it so much alongside with Signal and other slave tech. Although, unlike Evgeny, I'm generally not against federated networks because I value freedom of association more than freedom of speech. In other words, people should be able to decide what kind of content is allowed in their chat rooms/forums regardless or their political affiliation, religion, ideology, etc.
> SimpleX network is designed for extreme decentralization — not only users are distributed across network operators, as happens with federated networks, but each conversation will be relying on servers of 4-6 independent operators, and these operators will be regularly and automatically changed in the near future.
I want to emphasize, though, that SimpleX has an interesting architecture and it has potential to transition to a fully decentralized network with strong metadata protections, but that might take many years and I'd argue that constantly misleading its users is not a good strategy. Well, unless you're simply trying to get more funding... LN devs, I'm looking at you since 2017.
I also highly appreciate SimpleX's detailed documentation.
And if you think that the Session team is fully honest with its community, think twice.
- The whole situation with OXEN to SESH transition is a complete mess.
- There is no big warning against using "privacy" coin OXEN for any sensitive stuff due to low network activity. That can seriously compromise unaware users.
- The team has recently responded to criticism, but failed to link the original source, suggesting they don't want users to assess evidence independently.
https://getsession.org/blog/a-response-to-recent-claims-about-sessions-security-architecture
https://soatok.blog/2025/01/14/dont-use-session-signal-fork/
## Summary
The bottom line is that no messaging app provides full privacy. SimpleX and Session have different architectures for different use-cases.
- If you want an uncensorable username, an ability to recover an account with seed words, decent default privacy without PFS, then go for Session.
- If you want to run your own infrastructure or have an ability to easily create new identities, then go for SimpleX.
- If you need all of that, then simply use both.
I feel like the perfect messaging app should share Spasm fundamentals like being a fully agnostic modular open ecosystem. In that sense, SimpleX seems to be a bit closer to Spasm than Session, because it allows users to run their own infrastructure and it experiments with integrating other solutions as modules. Also why everything starts with "S"..?
To wrap it up, Session and SimpleX devs should finally man up and face each other in a proper ~~cage fight~~ technical debate instead of talking bad about each other behind the backs. Unfortunately, at this point it seems like both teams are simply afraid of such a debate since that can trigger public discussions about flaws of their products.
And if you think that I'm being too critical, then it's simply my love language <3
> Don't trust, verify.
Now you can argue here that it doesn't matter whether developers mislead the public since I have to verify everything by myself. I would agree with that, but it's also very hard to have expertise in all the fields, so it would be nice to be able to trust at least somebody.
But when FOSS developers manipulate the facts and industry "experts" use Signal, Matrix, Twitter, YouTube, Amazon, banking, and sim cards, then who do you turn to to trust?
### Feedback
If you've spotted any errors or have additional information, you can reach out to me privately at `degenrocket` on Session or join a public discussion by replying via your native Nostr app like Amethyst or by signing a comment with Ethereum or Nostr private key on Spasm instances, the list of which can be found at https://spasm.network