As far as I remember, Watchman Privacy was very soft when it comes to privacy and he had a paywalled privacy guide. I've once listened to his podcast episode with SimpleX's CEO Evgeny Poberezkin and it was such a softball interview. In other words, that interview did more harm than good. That said, I haven't followed Watchman Privacy, so he might have some good content as well. If anybody wants to interview SimpleX devs, please do some research first, you can start with this article - https://monero.top/news/spasmid010a70651fc27fb9125f7ea

> That statement is incorrect. Queue identifier is different for each pair of users, not for each user, so it cannot be used to understand who is connected to whom, and even how many users are there.

That statement is correct. I'm not sure which part of the statement you disagree with, so let's break it down into two parts.

The first part simply acknowledges that SimpleX has a message queue identifier (ID) for each contact/chat, which is clearly written in its docs. For example, if Alice opens three one-on-one chats with three contacts, she will have three chat IDs, which will be used to receive messages. Are you challenging this part?

The second part says that these IDs can be correlated through a metadata analysis. I described a few attacks in the article. For example, Alice goes online and checks if she has any new messages by providing these three IDs, which can be easily correlated into a shadow account based on timestamps and an IP address. That's also referred to as clustering of request batches. Are you challenging this part?

> That is not clear what metadata is suggested to analyse here. This can be done with GPA traffic analysis, but the same would apply to any network. Asynchronous delivery makes such attacks harder.

Timestamps, IP addresses, and even internet speed/ping can be used to correlate chat IDs into shadow accounts, I've explained that in the article and also in the Alice example above. Other networks (Tor, Session) have better metadata protections due to a proper 3-hop onion routing. That said, most networks are vulnerable to timestamp-based attacks, but they usually don't claim to be "100% private" with no IDs, etc.

> This is incorrect. Tor has three relays between the user and destination computer. SimpleX has two relays between the user and destination computer. So it's either 1 vs 2 hops, or 2 vs 3 hops. Unless you are counting some different hops.

SimpleX uses a 1-hop routing. I've already provided an example with Session in the article, but since you insist, let's also compare SimpleX with using a centralized messaging app via Tor.

`SimpleX: Alice - 1 relay - receiving server - Bob`

`TG+Tor: Alice - 3 relays - Telegram server - Bob`

1 vs 3 hops. Please provide an example if you dispute this statement.

And I'll repeat again the Session example from the article.

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

Are you disputing this? Please provide an example.

Well, the Church of Fluffy Pony is doing exactly the same to Ethereum, Solana, DeFi, and memecoins, failing to admit that Bitcoin itself is the oldest memecoin.

Try being completely bankless with just BTC and XMR, it's very hard. Now, other ecosystems like Ethereum and Solana give you permissionless self-custodial access to stablecoins, trading, leverage, prediction markets, governance, unique usernames, non-Nostr-based social graph solutions, and Spasm-powered forums.

As a freeman, I don't limit my freedom with religious crypto bs, so I use all of the above.

Monero - payments

Bitcoin - conservative savings

Ethereum - DeFi, NFTs, voting, usernames, Spasm

Solana - memecoins

Hey Ross, glad to see you on Nostr.

I've read your medium article. You're thinking within slave tech architecture, even your terminology like decentralized social protocol (DSP) is from the dinosaur era. The problem of most decentralized social media ecosystems is that they try to create a native solution for everything. Spasm is different because it's modular and agnostic, that's why it's the endgame of social media.

Don't get me wrong, I like Nostr, I know many Nostr devs, I was one of the winners of the first Nostr hackathon, and I've started integrating Nostr into Spasm in 2023. That said, Nostr is a closed ecosystem and it's at least one generation behind Spasm.

Let me take you on a wild Spasm ride so you can understand what I mean.

Firstly, let's see why Nostr is a closed ecosystem. Note that I use "ecosystem", not "protocol".

- Nostr locks you to one specific private key.

- Nostr locks you to one specific messaging protocol.

- All native Nostr apps support only one network.

- Most Nostr users use native mobile apps, which don't provide much freedom to e.g. sign arbitrary messages like web3 browser extensions.

- Nostr's most popular npm package 'nostr-tools' doesn't even expose a function to sign arbitrary messages, which is the most basic expectation of pretty much any other web3 library.

- The most popular Nostr app, Damus, is literally an iOS app.

- Most core devs are bitcoin maxis.

- The Nostr network is pretty centralized.

In other words, Nostr, SSB, Lens, Farcaster, Steem/Hive, Bluesky are much more open ecosystems than legacy social media platforms. However, when Spasm entered the room, the bar was raised so high that it became obvious that Spasm is the only truly open ecosystem, leaving all previous generations of social media as closed ecosystems.

Let's look at a few examples and how issues raised in your article can be solved.

Usernames are easily solved with an agnostic solution. Since Spasm supports different private keys, it can get the best from different ecosystems. For example, a non-unique name and bio can be fetched from Nostr, while a unique username can be fetched from various blockchain-based naming services like ENS. And there are privacy-preserving blockchain-based solutions, e.g., Zano aliases. Zano private keys have not been integrated into Spasm yet, but we've already discussed that option and it might happen this or next year.

Spasm is capable of what you're describing in the article because it can gather content from different networks, including Twitter-style social graph-based friend circles and Reddit-style niche forums.

The Spasm-powered forum also supports groundbreaking multi-signing, which allows users to sign the same message with different private keys and different messaging protocols and send it to different networks, while still having the same deterministic Spasm ID, meaning that all reactions and replies can be properly chained to the parent event regardless of the network they came from.

For example, I've published a detailed review of Session vs SimpleX architectures on MoneroTop.

https://monero.top/news/spasmid010a70651fc27fb9125f7ea

However, you can read the same article on DegenRocket because it partially federates with MoneroTop.

https://degenrocket.space/news/spasmid010a70651fc27fb9125f7ea

You can also read it on other Spasm instances that federate with DegenRocket using short or long Spasm ID, e.g.:

https://dark.vegas/news/spasmid010a70651fc27fb9125f7ea9f945d6add3530af91c829cdc414bcd5dda080f3020

Since that event is multi-signed with both Ethereum and Nostr private keys, it has multiple IDs, so you can access it using a Nostr ID on any of the instances mentioned above, e.g.:

https://monero.top/news/note1e94uvd0vx2k9mgdgnzzpqmdh0swkqmkhq6uy4c2g3pganxy96pvqlkvmsz

Additionally, this event was pushed to the Nostr network, so you can find it via your native Nostr app, e.g.:

nostr:note1e94uvd0vx2k9mgdgnzzpqmdh0swkqmkhq6uy4c2g3pganxy96pvqlkvmsz

Thus, you can get benefits from different networks and blockchains like Nostr's social graph and profile info as well as Ethereum-based social graphs provided by Farcaster or Lens and unique blockchain-based usernames like ENS. Nostr integration has already been implemented, while Farcaster, Lens, ENS, and other Ethereum-related integrations can be added later.

You can reply to the event with Ethereum or Nostr browser extension on a Spasm instance or using your native Nostr app as if it was a usual Nostr event.

Spasm-powered forums use reactions instead of flags, which can be used to filter content. Spasm instances can choose which reactions to use.

You're also focusing too much on ads in your article, which are mostly used in highly centralized networks with millions of users who don't have a habit of paying for social media services. There are many other ways to sustain a decentralized network, especially if it's not based on a social graph. Most Nostr apps currently rely on a social graph to show messages from a follow list and that requires huge Nostr relays with millions of events in order to provide good UX, which leads to centralization of the network.

There are other approaches, though. For example, Spasm is an agnostic solution, so it supports not only the Nostr network, but also other networks with different models of content distribution. Spasm-powered forums are mostly targeting many niche communities, which often don't require any ads to pay for infrastructure. Think about a conference that runs a Spasm instance so users can discuss details of the upcoming events on one forum, or a marketplace that runs a forum to discuss different products and vendors, or any other business or local community that can host a forum without serving any ads. These forums can also federate with each other, creating a highly decentralized and censorship-resistant network that doesn't rely on ads.

Let me know if you want to learn more about Spasm and the future of social media in general. You can reply to this message, send me DM on Nostr, find me on Session at 'degenrocket', or simply read more at https://spasm.network

> But I agree that it seems Simplex is being more deceptive. But both are bad.

Just like in politics, it's on journalists and industry experts to scrutinize projects like Session and SimpleX. Sadly, they've been letting it slide for the last few years.

Hopefully this article sparks some tough questions, especially about SimpleX's architecture, its misleading marketing practices, and the Trail of Bits audit. To make sure that we get an actual private messenger privacy experts should be grilling SimpleX, not giving it a free pass.

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

Oops, forgot to sign it with the Ethereum private key. OK, this reply is signed with both Ethereum and Nostr private keys and is sent to both Spasm and Nostr networks.

This post can be used as a playground to test Spasm without overthinking. Feel free to reply with any nonsense, 'test', or attach memes. You can also try markdown and other stuff.

This message is signed with Ethereum and Nostr private keys and pushed to Spasm and Nostr networks. You can submit comments or reactions with a temporary guest account or with Ethereum and Nostr private keys at the Spasm instance, as well as reply via your native Nostr app.

Spasm is the endgame of social media: decentralized, censorship-resistant, and fully agnostic, letting you use your own app to sign messages with any protocol, any private key, and send them to any network - we don't care, you do you.

Read more: https://spasm.network

Don't overthink it, just reply.

I've been also dreaming about adding support for PGP keys to Spasm, giving PGP users a tool for censorship-resistant public communication, but haven't yet found time to implement that since the UX/UI will be very clunky comparative to Ethereum/Nostr experience. Let's hope for 2025/2026.

> When Android and iOS apps?

Apple is slave tech, free people don't use iOS. That said, anybody can develop a Spasm-compatible iOS app.

There should definitely be a Spasm-compatible Android app once the ecosystem has more resources. At the moment, you can save Spasm instance on your home screen since it's PWA and read all the content.

You can submit messages to Spasm from a mobile device using:

- anonymous guest accounts that don't require any extra app,

- Brave browser using Brave wallet,

- Ethereum apps like MetaMask with built-in web3 browsers,

- browsers like IceRaven with support for Nostr extensions.

ShadowRebel from SimplifiedPrivacy made a video tutorial about using Spasm on a mobile: https://rebelnet.me/news/0xc5c7e9706d65f10d29

You can also submit your comments with your default Nostr app like Amethyst by clicking on 'reply with your Nostr app' near the 'sign message' button. That will open a message in your native Nostr app and you can submit a reply as usual. However, keep in mind that such messages will not be propagated through the Spasm network, but they will show up as replies on all Spasm instances that enable the Nostr network like https://monero.top

> Would you consider Farcaster and Blue Sky to be open ecosystems?

Farcaster and Blue Sky are from the same generation of decentralized social media platforms as Nostr and Lens, mentioned above. They are much more open comparative to legacy social media such as Twitter, Facebook, and Telegram, but they are still closed ecosystems as they lack interoperability and require usage of certain private keys, networks, and messaging protocols.

My favorite solution in that generation of social media protocols is Nostr due to its offchain approach. That's why I've started integrating Nostr into Spasm in 2023. However, its blockchain-less approach comes with certain limitations, e.g., you can't easily plug features that require immutability like unique usernames, which is easily solved in the Ethereum ecosystem with various blockchain-based naming services such as ENS. Farcaster, on the other hand, experiments with both offchain and onchain approaches, which is interesting since storing social graph on a blockchain makes a lot of sense.

In general, I'm not very bullish on Farcaster, Lens, and Blue Sky at the moment, but they have intelligent developers and a lot of funding, so they might come up with something interesting in the future.

Spasm is the next generation of decentralized social media and it's the only open ecosystem at the moment since it's agnostic to signing keys, messaging protocols, transport layers, and storage infrastructure. Spasm already supports Nostr and will integrate other good solutions in the future.

> There are many open ecosystems such as Nostr or Lens. How is Spasm different?

Nostr and Lens are indeed much more open ecosystems comparative to legacy social media such as Twitter, Reddit and Telegram, which are centralized platforms with zero interoperability. However, Nostr and Lens are very closed ecosystems comparative to Spasm because they require users to use certain private keys, networks, messaging protocols, etc.

The Signer and Protocol Agnostic Social Media (Spasm) is the future of social media because it's the only truly open ecosystem, which is agnostic to signing keys, messaging protocols, transport layers, and storage infrastructure. Users are able to sign messages with any private key of their choice and trigger the propagation of those messages in any network they want via any transport protocol, or even all at once.

Besides, Spasm integrates other solutions as modules. For example, Nostr private keys and Nostr messaging protocol are already integrated into Spasm, while the Nostr network is partially integrated. If Lens will come up with something good, e.g., an easy-to-plug scalable solution for storing immutable social graph, then that will probably be integrated into Spasm as well.

> Why without funding?

Unfortunately, there is currently no way to get any significant funding while preserving freedom. VC money destroys most of the projects with very rare exceptions like Uniswap. Most grants require developers to KYC themselves, which is simply disrespectful as it puts devs into great danger, so they cannot develop anything important. Donations can rarely provide enough funds for new projects.

> Have you tried gitcoin?

Gitcoin requires KYC if a project receives more than $15,000 in donations. Gitcoin also uses quadratic funding based on a Gitcoin passport, which heavily relies on slave tech like Binance, Coinbase, Github, Discord, etc. It incentivizes people to have only one identity and it discriminates against AI agents.

Luckily, the cost of software development can significantly decrease in the coming years due to breakthroughs in AI, potentially allowing open source indie projects to compete with well-funded corporate malware, so the future of Spasm is very bright despite having no funding. Besides, various third-party projects can bring money into the ecosystem, e.g., DarkVegas has recently airdropped its token to Spasm users. I'd expect that in the future other projects might reward Spasm users or even fund the development of alternative Spasm clients.

Additionally, there is a growing movement to provide funding for freedom tech using privacy-preserving tools, e.g., LunarDAO and the whole DarkFi ecosystem.

> Why is my username FluffyZkKitty lol. Can I change it?

It's an auto-generated name for better UX on Spasm instances. You got a good one lol. "Fluffy" is inspired by Monero dev Ricardo Spagni known as Fluffypony, "ZK" stands for zero-knowledge, and "kitty" is a tribute to the CryptoKitties NFT game of 2017.

You can choose your own non-unique name if you use Nostr keys, or get a unique username via blockchain-based naming services like ENS if you use Ethereum keys.

> Can I see Nostr replies here?

It depends on your definition of "Nostr replies". Nostr is not one monolithic thing like Twitter or Telegram. Nostr is at least three different things: Nostr private key, Nostr messaging protocol, and Nostr network.

We got used to thinking about each social media solution as one monolithic thing due to decades of influence by traditional VC-backed platforms that try to register a trademark, expand fast, compete with other platforms, and keep users inside their closed ecosystems to monetize them. In reality, good decentralized social media solutions are modular.

So yes, you can see all Nostr-signed messages that were submitted to the same Spasm instance. However, you cannot see Nostr-signed messages that were submitted to the Nostr network only. That feature will be added a bit later. You can already see messages from both Spasm and Nostr networks on the author page of any up-to-date Spasm instance, e.g.:

https://monero.top/authors/npub1kwnsd0xwkw03j0d92088vf2a66a9kztsq8ywlp0lrwfwn9yffjqspcmr0z

There are no immediate plans on launching SPASM token, but operators of Spasm instances are free to launch their own community tokens and potentially token-gate their forums as an alternative to whitelisting.

For example, DarkVegas launched a token BLOOD in 2023 and recently airdropped it to Spasm users:

https://dark.vegas/news/note1gd5377tsmtvpr79cefvj2th6phu0fptzfmxek95n7pnk3jw6dtsq3zpwpt

> When did you start working on Spasm and why?

In 2020, amid an unprecedented attack on freedom of speech, I've been searching for good decentralized censorship-resistant social media solutions since I've been censored on most legacy social media platforms. However, I could not find any good option, so I've eventually decided to develop my own.

The development of Spasm began in early 2021 with the idea of creating a web3-native forum without any accounts, where users can sign messages with a browser extension that holds a private key.

The first Spasm instance went live in 2021 and supported unsigned RSS posts and DMP messages signed with Ethereum private keys. Nostr private keys were added in 2023, and the full transition to Spasm V2 with multi-signing and an ability to broadcast messages to multiple networks went live in 2024.

You can read more about Spasm history here:

https://monero.top/news/note1whtyfc6xcyntfurs6ndk395jr8vxxdp3aynmhatrp5gqpxpp0cyslk62ry

> Where can I find an official documentation? Your Spasm github repo didn't get updates for a long time.

There are two github repos for Spasm. The repo with the most stars briefly explains the concept of Spasm and it haven't received any updates since 2023. However, there is a pretty good README file for the frequently updated spasm.js npm library, which you can find here:

https://www.npmjs.com/package/spasm.js

https://github.com/degenrocket/spasm.js

Choose private key agnostic solutions, it's the whole point of decentralized social media.

Spasm+Ethereum+Nostr is a super power, you are not tied to any private key or network.

I'm happy to answer any questions about Spasm.

You can also read today's full AMA:

https://monero.top/news/spasmid01e7b984794c6a8278ad896

If you're a developer, then check out spasm.js library:

https://www.npmjs.com/package/spasm.js

And there is a post from December about Spasm history, its infrastructure, as well as pros and cons of the Nostr ecosystem:

note1whtyfc6xcyntfurs6ndk395jr8vxxdp3aynmhatrp5gqpxpp0cyslk62ry