Nostr notes by degenrocket

Yeah, great questions, I should add some of them to FAQ. > ...

2026-03-31T03:34:06Z

In reply to nevent1q…eysq
_________________________

Yeah, great questions, I should add some of them to FAQ.

> From a frontend and user experience perspective, most of the existing Spasm forums appear visually outdated. Is there an established roadmap for improving UI/UX, or is the expectation that developers build fully custom frontends on top of the protocol?

I love the current forum UI, been using it for 5 years now. It was inspired by CryptoPanic and LIHKG, but yeah, many people say that it's outdated. There are plans to provide alternative UI options, so admins can switch different themes with a click of a button. In fact, the new web admin panel already provides a lot of customization options via GUI. It currently applies to colors, favicons, header images, titles, descriptions, and other small things, but there will be more options later this year. Ideally, we should have 2-3 completely new UI themes.

And yes, this is just an official web client, but devs can build whatever they want. In fact, people are already doing that. Moving forward, even if custom frontends become mainstream, the official Spasm client will provide admins with an easy option to manage nodes.

As for the roadmap, the current focus is on growing the network by providing easy deployment methods since multiple communities expressed interest in joining the network, but faced challenges when deploying nodes.

**Admin panel**

The web admin panel has already been fully reworked, so admins don't need to touch `.env` file beyond specifying admin pubkeys.

You can check a new web admin panel at:
https://forum.spasm.network/admin

**Docker/Podman**

We just released a Docker/Podman deployment option last week, essentially a "one-click" setup for existing servers.

It's not just easy to deploy and manage, but also highly secure: the frontend and backend run in isolated containers. If you use Podman, it runs rootless and daemonless. Containers are on an isolated network and don't expose any ports to the host. They communicate via Docker's DNS and only expose a single port (33333) to the host via an Nginx proxy container. The result is maximum security with minimal effort since admins only need to map one port to a domain name.

We're still testing it, though, so it hasn't been announced yet, but you can already check the git repo:
https://github.com/spasm-network/spasm-docker

**Ansible**

I'm also completely reworking the deployment method on a new server for people without much DevOps experience. We're finally moving away from older bash scripts to Ansible playbooks.

This new "one-click" approach handles full idempotent deployments from scratch. It automates everything: building the server, applying hardening, and pushing the app. It will also include server management scripts to simplify the process.

The new Ansible deployment method should be released this or next week.

**Federation via GUI**

For years, federation required manual config files, but it's finally moving to the web admin panel. This will drastically simplify the process and help the ecosystem grow.

**Skill**

We also started working on SKILL for AI agents, but we paused to prioritize deployment tools since that was the community's biggest request right now. Once Ansible and GUI federation are live, SKILL will be finished and released.

After that, we'll tackle other feature requests. Anyway, we always consider suggestions from the community, so let us know what exact features are you looking for.

> On that note, can Spasm be seamlessly integrated into a completely custom frontend (non-forum style)? Are there any existing themes, frameworks, or production-level examples that demonstrate this being done successfully?

Yes, Spasm can be integrated into any frontend. There is npm library that can be installed into any project.

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

If you don't use any frontend framework, then there is a bundle that you can import into a browser.

https://github.com/spasm-network/spasm.js/blob/master/dist/spasm.min.js

We don't build alternative frontends ourselves, but Spasm is already powering other projects. For example, the Unblocked team started integrating Spasm into their IPFS-hosted ENS templates in early 2026. We are not affiliated, but their project has very interesting architecture. I'm not sure whether they opened source it yet, though, but you can check an example here:

https://jsunblaze.eth.limo/

Check out the CID player section. Each track is a Spasm event fetched directly from their Spasm instance. Each event has an IPFS link to an audio file. Essentially, ENS used as DNS, IPFS as hosting for website and media, and Spasm handles social aspects like posts, comments, likes. By the way, Spasm can handle media as well, but they prefer IPFS for that.

And you can also fetch Spasm events from different Spasm instances. In fact, they are doing exactly that for a different Spasm search project. Anyway, as I already mentioned, we're not affiliated, so I'm not up-to-date with all the things they build.

> I’m also looking for clarity around real-world use cases. Beyond forum-style discussions, how is Spasm currently being leveraged in live applications (e.g. social feeds, content and media platforms, comment systems, follow systems etc.)?

I already provided examples above, but in general, you can build anything with Spasm. You mentioned ethcomments, so I assume that you come from the Ethereum ecosystem. Have you heard about Nostr? It's pretty cool despite being developed by Bitcoin maxis. You can build almost anything with Nostr even though it's a closed ecosystem. Think of Spasm as Nostr, but a generation ahead. Spasm has fully agnostic architecture supporting multiple private keys, protocols (Spasm, RSS, Nostr, Dmp), networks, etc.

In other words, Spasm is a truly open ecosystem and the endgame of social media. And yes, this isn't just marketing - it's the reality.

> Can comments be retrieved and displayed via API in external applications?

Yes, you can get events from any instance via API as an array of SpasmEnvelopeV2 using many different filters like categories, actions, activity levels, etc.

https://github.com/spasm-network/spasm-forum-server/blob/master/docs/api.md

Once you fetch an array, you can convert it to an array of SpasmEventV2. The function will also verify all the signatures and sanitize malicious stuff.

```
// Spasm Envelope is a compressed version of Spasm Event.
// It's used to reduce bandwidth when exchanging events.

// Spasm Event is an uncompressed version of Spasm Event.
// It's important to convert received envelopes to Spasm
// events because that will verify signatures.

// Convert one event to Spasm Event
const spasmEvent = spasm.convertToSpasm(event)
// Convert many events to Spasm Events
const spasmEvents = spasm.convertManyToSpasm(events)
```

In fact, spasmjs npm library also provides a function to convert a legacy RSS feed to an array of Spasm events in case if you need that `spasm.convertRssFeedToSpasm(rssFeed)`.

By the way, SpasmEventV2 has a very complex structure, but spasmjs npm library provides tons of utils to simplify the development process, so it should be fairly simple to integrate Spasm into your frontend with the help of AI agents, especially if you're only planning to support one private key like Ethereum.

There is also a universal `spasm.fetchEvents()` function, which just fetches whatever you want from Spasm instances to legacy RSS feeds and converts all of that into array of SpasmEventV2. I've started developing it while working on SKILL, but then got distracted with Docker/Podman/Ansible, so the function is not finished yet, but it will significantly simplify the development process once it's ready.

> Does the network automatically propagate and synchronize posts across multiple Spasm instances?

Well, you can integrate Spasm events with your own solution for events storage and propagation. You can even store Spasm events onchain. That said, if you want to use existing Spasm instances, then they are very flexible since the network is based on optional federation.

Admins can tailor federation rules to fit their needs, for example:
- Fetch only "rising" posts in the "DeFi" category from Instance A every 10 minutes.
- Pull only "hot" posts from the "Privacy" category from Instance B hourly.
- Fully mirror a third instance.
- Apply custom moderation policies.

Once Federation GUI is live in a web admin panel, you will easily understand how it works.

> What level of control do developers have over how content is indexed, filtered, and displayed across different frontends?

Admins of instances can impose any moderation rules they want. If you're building a frontend-only solution, you can connect to any instance using filters you define. You can also implement any automated moderation policy on a client-side. However, to provide specific details on moderation options, I'd need to know more about your architecture.

> How does identity and authentication scale (wallet-based, signatures, etc.) across different apps and nodes?

I'm not sure if I fully grasped your question, but on the official Spasm forum, users can directly connect Ethereum and Nostr apps. For example, Ethereum browser extensions (Rabby, MetaMask), mobile apps (MetaMask), desktop apps (Status), etc. On your own frontend you can implement whatever you want from modern solutions to legacy MEW-style keystore files.

> Are there any limitations or bottlenecks when building high-traffic applications on top of Spasm?

Years of development have taught me one thing: there's nothing we can't solve. The only potential bottleneck might be adjusting database indexes for faster retrieval on high-traffic nodes, but that's a minor detail. Again, I'd love to know more about your specific architecture to give you a better answer.

> This looks very interesting and simular to other projects like ethcomments.xyz but they use a more centralized behavior. We like the node system and instances populating as a decentralized concept.

Yeah, Spasm started in 2021. It's the most open ecosystem and represents the most advanced generation of decentralized social media. It always bugged me why so many people choose closed ecosystems and outdated solutions. I suspect people are more drawn to tribalism than to true freedom.

> Lastly, where is the best place to review technical documentation, architecture breakdowns, or developer resources that go beyond the basic forum. Can you direct us to a Spasm system being used outside of the basic forum structure ?

You've probably seen our docs, so I'm not gonna mention it. We also have a new git repo with reference modules, but it's still fairly new:
https://github.com/spasm-network/sperms

In general, reach out to `degenrocket` on Session if you want to chat. We also have a few groups there with admins, devs, and early adopters.

Farcaster was just another VC-funded cash grab, slapping trendy ...

2026-01-25T23:24:55Z

In reply to nevent1q…yrda
_________________________

Farcaster was just another VC-funded cash grab, slapping trendy words like "decentralization" and "crypto" on their pitch deck to get investors. Swapping out the original founders for some "community devs" won't fix the broken architecture. It's still a walled garden dressed up as something revolutionary, a closed ecosystem that requires the usage of one private key, one protocol, and one network. Neynar clearly states in the acquisition announcement that it runs infrastructure of Farcaster.

Spasm operates on fundamentally different principles because it was architected from day one as a genuinely open ecosystem. Unlike its centralized counterparts, Spasm embraces true interoperability by supporting diverse private keys, multiple protocols, and various networks. Most importantly, its infrastructure isn't controlled by any corporate entity but is collectively maintained and governed by the community itself, ensuring it remains resistant to the capture and acquisitions that plague supposedly "decentralized" projects from Steem to Farcaster.

The actual roadmap to creating a consent-based society based on ...

2026-01-20T01:29:56Z

In reply to nevent1q…8yrd
_________________________

The actual roadmap to creating a consent-based society based on libertarian principles such as the freedom of association is a different topic. Establishing new governance systems with legitimate geneses on uninhabited territories represents a promising solution, particularly as technological advances enable human colonization of Antarctica, oceans, other planets, and space in general.

However, we can also reform the existing systems by reducing federal government powers, transferring greater authority to municipalities, and establishing robust institutions dedicated to protecting decentralization and freedom of association. Additionally, implementing Prospera-inspired special economic zones would introduce competitive governance, paving the way for a 'government as a service' paradigm where individuals choose their preferred administrative frameworks rather than being bound by territorial monopolies.

In attempt to be more platform-agnostic, we are dedicating more ...

2026-01-03T23:30:49Z

In attempt to be more platform-agnostic, we are dedicating more effort to evaluating the Status app and investigating potential integrations with the Logos ecosystem.

Status has a very different architecture from other freedom tech apps like Session and SimpleX. It is built on top of Logos Messaging (formerly the Waku network), which consists of relays and storage nodes, and employs rate-limiting nullifier (RLN) to mitigate DoS attacks. Following an eight-year development journey since its 2017 ICO, Status has recently shipped a new unified super-app that integrates a crypto wallet, a web3 browser, and a privacy-focused messenger.

You can get the new mobile app on Android and iSlave through legacy app stores, and it should hit F-Droid soon. Unfortunately, no direct APK downloads for now, but you can grab the new desktop app from the official website.

On our end, Spasm-powered forums are running on Spasm and Nostr right now, and we're planning to add more networks later this year. But the expansion requires careful consideration of practical use cases and the development of robust integration architectures. For example, the Spasm network is the backbone of the Spasm ecosystem based on highly customizable, federated message propagation system across many instances, while the Nostr network provides a more centralized-ish solution for an offchain social graph, allowing people to follow each other via Nostr apps.

As we continue our research into leveraging Logos Massaging for Spasm forums to bridge these two ecosystems, we'd love you to test out the Status app with us and share your experience, feedback, ideas, or questions. The Logos team already answered many questions about its messaging network last year, which you can read in [another post](https://zkpunks.dev/news/spasmid01077e4712459dafc005ed6ca59f4d33f0ba58516591e71784b79ad767410e2cb3).

While Status isn't perfect, no app is, it's a solid tool for anyone looking to unplug from slave tech.

If you already have the Status app, you can join the zkpunks community via [this link](https://status.app/cc/G4MAAGTq3D2t7GmY9LVokIlHtA0ccuDQlmBgmad8wMBDVtqbi6biD0TuWSIDVGP0JkMigqMplXwex3Nqj1fj9CRpK0GGyH39ck79DqXl3PdXsW52GWA3gB0jKFOvDNyU-rkVUs8PYxoXeUwtq3Dy1C0cO_AB#zQ3shvLb2TmuRreZ57VCLynfX5ukoqR275M7DMJDsC8BZvabs).

Yes, there are plans to add an RSS feed to Spasm forums, so users ...

2025-12-07T18:58:39Z

In reply to nevent1q…tfzz
_________________________

Yes, there are plans to add an RSS feed to Spasm forums, so users can follow podcasts using outdated tech as well. An RSS feed can be hacked to also include the whole Spasm event with signatures, allowing legacy tech that relies on RSS feeds like AntennaPod to transition to web3 whenever they feel ready.

The standard practice of storing your NPM token in a plain text ...

2025-11-26T23:57:57Z

The standard practice of storing your NPM token in a plain text file isn't just lazy; it's a security disaster waiting to happen. With NPM supply chain attacks becoming a regular event, leaving your NPM token unencrypted is like leaving a public dildo on your front porch. It's an open invitation to get fucked. Hard.

While the whole NPM ecosystem is slave tech that cannot be fixed, let's at least get some basic protection by encrypting access tokens.

Firstly, create a new NPM token and encrypt it with OpenSSL:

```
echo -n 'YOUR_NPM_TOKEN' | openssl enc -aes-256-cbc -a -salt -pbkdf2 -iter 1000000 > ~/.npm/tokens/.npmtoken-your-project.enc
```

Then, create a bash script to publish your NPM package using this encrypted token:

```
#!/bin/bash

cd ~/path/to/your/project/

# Prompt for the passphrase
read -s -p "Enter passphrase for .npmtoken-your-project.enc: " passphrase

# Decrypt the token
npm_token=$(openssl enc -aes-256-cbc -d -a -salt -pbkdf2 -iter 1000000 -pass pass:$passphrase -in ~/.npm/tokens/.npmtoken-your-project.enc)

# Check if the decryption was successful
if [ $? -ne 0 ]; then
echo "Decryption failed. Aborting."
exit 1
fi

echo "Token is decrypted."

# Assign the decrypted token to the NPM_TOKEN environment variable
export NPM_TOKEN="$npm_token"

# Make sure that authToken set to NPM_TOKEN in ~/.npmrc
# //registry.npmjs.org/:_authToken=${NPM_TOKEN}

# Use the NPM_TOKEN environment variable for npm publish
npm publish --registry https://registry.npmjs.org/

# Check the exit code of npm publish
if [ $? -eq 0 ]; then
echo "Package published successfully!"
else
echo "Error: npm publish failed."
exit 1
fi

# Clean up the token from the environment
unset NPM_TOKEN

echo "Done."
```

Next, save this script into `~/.local/bin/npm.publish.your-project` and make it executable.

```
chmod +x ~/.local/bin/npm.publish.your-project
```

Now you can publish your NPM package by executing this script, which will prompt you to enter your password:

```
npm.publish.your-project
```

By encrypting your token with OpenSSL, you're not removing the dildo from your porch, but at least you've put a lockbox on it. It's still a target, but now you've made the bastard work for it, which is more than most people can be bothered to do.

A genesis social contract, commonly referred to as a ...

2025-11-06T17:20:48Z

A genesis social contract, commonly referred to as a constitution, serves as the foundational document from which all other laws derive their legitimacy. In many societies, the constitution is the ultimate source of legal authority. However, the legitimacy of modern constitutions can be questioned.

For instance, the US Constitution, despite its historical significance, has faced scrutiny regarding its origins and the inclusivity of its authorship. As the second foundational document of the United States, it is the oldest written national constitution still in effect. The process of its creation and ratification was arguably more legitimate than in many other jurisdictions, involving extensive debate and compromise among the states. However, many libertarians argue that it remains an illegitimate document. Their claims are based on several key arguments.

Firstly, many anti-federalists did not agree with the new constitution, as evidenced by events like Washington's suppression of the anti-tax Whiskey Rebellion using militia. This highlights the internal conflicts and resistance to the centralized authority proposed by the constitution. There was significant resentment towards taxation, as people had recently fought a war against the British Empire for independence from the crown. The founding fathers then established a similar centralized authority, known as the federal government, with the power to tax people. Many saw this as a betrayal of the freedoms and principles outlined in the first constitution, known as the Articles of Confederation, fueling deep-seated opposition to the new constitutional framework.

Secondly, the right to secede was effectively denied when Lincoln's Union refused to allow the Confederacy to branch off during the Civil War. This denial of secession has been a contentious issue, with some arguing that it set a precedent for the forced unity of the states. Basically, denying people the right to leave.

Lastly, the constitution was agreed upon by a select group of people from the past, but their descendants never explicitly consented to it. For example, individuals born in the jurisdiction are forced to choose between paying federal taxes or leaving their homeland in search of a land of the free. This intergenerational imposition of governance raises questions about the legitimacy of the constitution in the eyes of those who did not explicitly agree to it.

While these issues are significant, this article will not delve into the options for creating a legitimate genesis social agreement or a pristine genesis. Instead, it focuses on the process of upgrading constitutions by proposing an alternative to the amendment process currently used in most nation-states, which often results in the tyranny of either the minority or the majority. This alternative aims to provide a more equitable and inclusive path for constitutional evolution, addressing the concerns of those who feel marginalized by the current system.

The process of upgrading a constitution is a contentious issue. Some individuals advocate for change, while others prefer to maintain the existing framework. Changing a constitution involves enforcing new rules on those who may disagree, which can lead to social and political tensions. This dynamic is akin to altering the rules of a game midway through, affecting all participants.

The solution proposed is an Immutable Genesis Social Contract. This concept allows for the existence of multiple versions of a constitution, each with its own set of rules. Some individuals can choose to adopt a new version, similar to how different versions of a software protocol, like Uniswap v2, v3, and v4, coexist. This approach provides flexibility and choice, allowing societies to evolve without imposing changes on those who prefer stability.

However, this solution faces its challenges. For example, the laws should be compatible enough to allow different groups live together within the same jurisdiction while adhering to different sets of rules. Historically, this has been the case, with rules often varying based on factors such as insurance coverage, wealth, residency status, religion, and even corruption. Additionally, differences in legal application based on race, gender, and age have been prevalent.

Another challenge is the potential for excessive legal divergence due to branching. To mitigate this, prioritizing simplicity and interoperability between different constitutional versions is crucial. This can be achieved by ensuring that new versions accept a significant portion of the laws from previous versions, thereby maintaining continuity and reducing fragmentation. Furthermore, the integration of AI can assist in navigating the complexities of a multi-constitutional legal landscape.

In conclusion, the immutable genesis social contract offers a framework for legal and social evolution, providing choices while maintaining order. It addresses the challenges of coexistence under different legal systems and the potential for legal fragmentation, paving the way for a more adaptable and inclusive governance model. This framework helps restore and maintain freedom of association, ensuring that individuals are not compelled to live under rules they do not agree with, thereby fostering a consent-based society where diverse groups can coexist harmoniously.

Nostr event nevent1qqspx76syfee7w732930fkdpyravgj8djn3ux2vtapv55rjuuwwzchqzyze6wp4ue6ee7xfa54fuua39thtt5kcfwqqu3mu9lude96v539xgzqqyzmw

2025-10-04T15:10:09Z

- On September 21st, the SPASM token was officially launched, marking a pivotal moment in the five-year evolution of the Spasm ecosystem
https://forum.spasm.network/news/spasmid0168fa37f818a60ddaa8af6
- Authors can now manually submit the same event to multiple instances through UI
- All Spasm repos moved to https://github.com/spasm-network
- DegenRocket forum rebranded as Spasm forum
- Updated docs website https://docs.spasm.network
- Added more tests and fixes to Spasm forum and spasm.js

Nostr event nevent1qqs9quhj0ftafufef00qte03fkc02v4s4s3vw3ardtweec065pjdaxszyze6wp4ue6ee7xfa54fuua39thtt5kcfwqqu3mu9lude96v539xgzy55qj5

2025-09-01T21:59:14Z

- The Battle of Virtuals Genesis Launch https://forum.spasm.network/news/spasmid014663badac2438303d5f5f

- New video about Spasm history

- New video about web3 auth vs Spasm-powered direct signing

- Spasm.js v2.0.0 moved to release candidate status https://www.npmjs.com/package/spasm.js
- Added Spasm hashes for media files.
- Images can now be embedded by simply adding image URL to a new line (can be disabled via env).
- Added more tests and fixes to DegenRocket web/server and spasm.js

What an epic battle! Launching on Virtuals was a bold move, as ...

2025-08-30T01:21:01Z

What an epic battle!

Launching on Virtuals was a bold move, as the platform is primary designed for AI agent launches, while Spasm is an infrastructure project. Yet, we recognized the potential and embraced the risk.

After years of development, it was truly amazing to see how many of you jumped in during the first ten minutes of the genesis launch, meaning that you were waiting for the launch. We were there with you, playing together as one team.

It was a tight race against the clock. In the first 5 hours, which was 20% of the allowed time, we made it to approximately the 20% mark of the target. That was a neck-and-neck battle.

However, as the clock struck the 10-hour mark, it became clear that time was not on our side. Yet, in the final hour, it was incredibly uplifting to see the surge of support, with a significant amount of tokens pledged, as people were still trying to win the lost battle.

This match had strict rules: 24 hours, 566 Virtuals ($650) max from each address. Many whales committed the maximum allowed amount of 566 Virtuals, which means the outcome could have been different if we had chosen a different launch option, allowing more tokens per address. But history remembers only the paths we chose.

The 400 Spasmers stood tall at the Virtuals Genesis Launchpad. For 24 hours, they held the line tirelessly, defending the very essence of decentralized freedom. In the annals of blockchain, the names of those 400 brave souls are inscribed forever. Their contributions will surely be acknowledged in the chapters yet to come.

https://basescan.org/address/0xea6327935b9a8295334b4fd06b3c786f0eb784fe

What's next?

We've been in this fight for half a decade, and we're far from done. We try, we fail, we learn, and we try again. We grow stronger with each attempt. Until we win, we persist, we adapt, and we overcome.

During the preparation for the Virtuals Genesis Launch, we forged new alliances that will stand with us on our challenging journey. And we found you, our partners in this quest. This is just the beginning.

We thank all participants; your commitment means a lot to us. We congratulate other teams that succeeded in the genesis launch, and we feel for those who didn't. Lastly, we thank the Virtuals team for the amazing opportunity to play this match and get more exposure.

The Spasm ecosystem is now stronger than ever, with more people discovering it and more communities eager to join. We're excited to continue our collaboration with the Virtuals team, exploring potential Spasm integration.

We will take a few days to reflect on the recent events and plan our next move.

Initially, we intended to launch on the Ethereum mainnet and decided to use a cutting-edge Virtuals launchpad, as they announced in June that Ethereum had become a viable option for genesis launches. However, it turned out to be a special deal for a specific project, leaving us with no other option but to attempt to launch on Base.

Ethereum, being the most decentralized smart contract platform, offers a more secure and censorship-resistant environment with greater liquidity for launching a token, and with the flexibility to bridge to different L2s and other blockchains like Base and Solana. Thus, we will now explore options to launch independently on Ethereum and keep you informed through our official channels.

Forum: https://forum.spasm.network
Twitter: https://x.com/SpasmNetwork
Nostr web: primal
degenrocket (npub1kwn…mr0z)
Session: degenrocket

Send us a message on Session to join our group chat. Session is one the most privacy-focused apps with decentralized infrastructure that doesn't require any email address or phone numbers.

Stay tuned for the announcement.

Spasm is the endgame of social media. Join the future!

Spasm V2 npm library has been stable for over a year and can be ...

2025-08-28T03:07:42Z

In reply to nevent1q…zxth
_________________________

Spasm V2 npm library has been stable for over a year and can be used by any projects, but we plan to keep it in a 'release candidate' state for a while to align with semantic versioning and avoid introducing breaking changes in minor releases, as too many projects do.

Thanks. Significant effort was put into research and development, ...

2025-08-28T02:55:21Z

In reply to nevent1q…ctwr
_________________________

Thanks. Significant effort was put into research and development, leading to many iterations of the protocol, which meant the network was not ready for expansion until around 2025. We then explored various growth opportunities and launchpads, which took a lot of time. After thorough testing and choosing Virtuals launchpad, we're finally ready to enter the expansion stage.

The airdrop strategy will be determined over the next few months ...

2025-08-28T02:49:08Z

In reply to nevent1q…hdpd
_________________________

The airdrop strategy will be determined over the next few months and may involve multiple rounds to reward existing participants, attract new ones, and expand the ecosystem, potentially including instance operators, code contributors, moderators, community managers, regular users, long-term genesis token holders, and even active participants from other ecosystems.

Correct, Rebelnet was active in 2024, but it has been down for a ...

2025-08-28T02:40:17Z

In reply to nevent1q…a3an
_________________________

Correct, Rebelnet was active in 2024, but it has been down for a long time.

Following a half-decade of development, Spasm is now entering a ...

2025-08-23T02:25:14Z

Following a half-decade of development, Spasm is now entering a new stage of expansion. To accelerate ecosystem growth and attract more attention, Spasm is leveraging the AI agents-focused Virtuals launchpad. Join the future.

https://app.virtuals.io/geneses/7657

After a year of rigorous testing, Spasm.js v2.0.0 is stepping up ...

2025-08-19T00:30:31Z

After a year of rigorous testing, Spasm.js v2.0.0 is stepping up from beta to release candidate status. Introduced in 2024, the new version brought groundbreaking features like multi-signing, propelling social media into the future. Now, it's your turn to test and shape the final version!

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

---

The Signer and Protocol Agnostic Social Media (Spasm) is the future of social media. 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.

The Spasm network consists of independent self-hosted interoperable instances run by DAOs, local communities, and other freedom seekers who want to escape censorship and surveillance of centralized platforms.

The Spasm ecosystem is the next generation in the evolution of social media after various signature-based decentralized ecosystems like Secure Scuttlebutt (SSB), Steem/Hive, Nostr, Farcaster, Lens, Bluesky, etc.

Connect your Ethereum or Nostr browser extension and join the future of social media.

> not your keys, not your words

Check out the latest in the Spasm ecosystem: - New Spasm forum is ...

2025-08-01T20:05:47Z

Check out the latest in the Spasm ecosystem:
- New Spasm forum is up: https://forum.spasm.network
- Official website refreshed with new sections: https://spasm.network
- Docs expanded with new pages and FAQs: https://docs.spasm.network
- More slides added to presentation: https://slides.spasm.network
- DegenRocket web/server and spasm.js npm library got new tests and fixes: https://github.com/degenrocket

Plus, we're eyeing Virtuals Genesis Launch to boost the ecosystem: https://forum.spasm.network/news/spasmid0126e98616d9a04eeb399bc

We're looking into leveraging an existing launchpad to get ...

2025-07-31T22:40:48Z

We're looking into leveraging an existing launchpad to get more attention and grow the Spasm ecosystem, while keeping things independent and avoiding the traditional routes of VCs and grants, which usually compromise privacy and project autonomy.

Spasm has been under development for over four years, but the ecosystem could really use a boost to hit the next level. We think that a launchpad could be the perfect catalyst.

Out of all the launchpads, the Virtuals ecosystem stands out as the top contender, because it provides an excellent opportunity to integrate Spasm-powered solutions into the emerging agentic economy.

What are your thoughts on the Virtuals ecosystem and ideas about Spasm tokenomics? From token use cases and initial allocations to airdrops, let's hear your thoughts!

You can now find all Spasm-related announcements and submit your ...

2025-07-17T00:43:07Z

You can now find all Spasm-related announcements and submit your feedback, ideas, feature requests, bug reports, and share memes on the official forum at https://forum.spasm.network

SimplifiedPrivacy runs a Spasm-powered forum, you can read the ...

2025-06-25T05:17:04Z

In reply to nevent1q…sv5w
_________________________

SimplifiedPrivacy runs a Spasm-powered forum, you can read the same thread on its website, as well as on other federated Spasm instances, with replies from both Spasm and Nostr networks.

https://forum.simplifiedprivacy.com/news/spasmid01f91e058945409d9f80140

Yes, Spasm is open source. It has been in development since 2021 ...

2025-05-10T18:47:07Z

In reply to nevent1q…ukkt
_________________________

Yes, Spasm is open source. It has been in development since 2021 and it's currently the most advanced generation of decentralized social media. You can find all the links at the official website https://spasm.network

Great news! I'd also add that ...

2025-05-10T03:14:00Z

In reply to nevent1q…j4jc
_________________________

Great news! I'd also add that https://forum.simplifiedprivacy.com now supports multi-signing similar to other Spasm instances, allowing 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.

Why would anybody sign a message with multiple keys? For example, you want to get benefits from different ecosystems. Non-unique usernames can be fetched from Nostr meta events (kind 0), while unique usernames can be fetched from blockchain-based NFT-powered naming services like ENS. Nostr users can follow you on Nostr, while Ethereum users can follow you on Lens, Farcaster, and other Ethereum-based social media platforms.

Nostr is definitely a better solution, but it's still a ...

2025-04-29T22:14:47Z

In reply to nevent1q…7vtu
_________________________

Nostr is definitely a better solution, but it's still a closed ecosystem.
- 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.
- The Nostr network is pretty centralized.

AI agents and their devs will eventually choose Spasm since it's the only truly open ecosystem due to its unique agnostic architecture.

> It would be nice if there was a business model for nodes and ...

2025-04-25T22:35:29Z

In reply to nevent1q…gnwr
_________________________

> It would be nice if there was a business model for nodes and node competition at the protocol level.

No, that's a recipe for creating a closed ecosystem that limits freedoms and stifles innovation similar to having a strong federal government that sets all the rules like requiring all devices to have a USB-C port.

Unlike Nostr or other decentralized social media solutions, Spasm is the future of social media because it's the only fully agnostic open ecosystem that doesn't limit developers or users.

As far as I remember, Watchman Privacy was very soft when it ...

2025-04-25T21:56:54Z

In reply to nevent1q…2932
_________________________

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

2025-04-24T23:07:38Z

In reply to nevent1q…36rs
_________________________

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

2025-04-23T22:11:59Z

In reply to nevent1q…q88s
_________________________

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

2025-04-23T03:02:33Z

In reply to nevent1q…6tvx
_________________________

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

quoting
note1e94…vmsz

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

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

2025-03-17T20:44:25Z

In reply to nevent1q…ezlm
_________________________

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

2025-03-15T07:49:16Z

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

2025-02-22T05:35:28Z

In reply to nevent1q…j2v0
_________________________

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

2025-02-22T05:33:23Z

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

2025-02-19T18:47:36Z

In reply to nevent1q…kx90
_________________________

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

2025-02-13T22:49:05Z

In reply to nevent1q…snk2
_________________________

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

2025-02-13T22:34:18Z

In reply to nevent1q…9nf8
_________________________

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

2025-02-04T04:29:44Z

In reply to nevent1q…pl7f
_________________________

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

2025-02-03T23:49:30Z

In reply to nevent1q…l5tn
_________________________

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

2025-01-28T20:31:17Z

In reply to nevent1q…r6nd
_________________________

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

2025-01-28T20:17:56Z

In reply to nevent1q…repj
_________________________

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

2025-01-28T19:56:31Z

In reply to nevent1q…5q6n
_________________________

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

2025-01-28T19:40:27Z

In reply to nevent1q…apt9
_________________________

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

2025-01-28T19:29:23Z

In reply to nevent1q…kzf0
_________________________

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

2025-01-27T21:00:22Z

In reply to nevent1q…c7qy
_________________________

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

2025-01-27T20:46:16Z

In reply to nevent1q…uvew
_________________________

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

> Musk's chaotic "move fast and break democracy" ...

2025-01-27T20:14:26Z

In reply to nevent1q…7qdm
_________________________

> Musk's chaotic "move fast and break democracy" Twitter approach

The US has never been a democracy by design. Most Americans who
religiously believe in the legitimacy of the second constitution have never actually read it.

Musk wants private cities with large autonomy so he can be a king, as well as build and launch rockets without bureaucracy and create new jurisdictions in space. Feds already approved special economic zones, so private cities might become reality within a few decades. DOGE is the key to that libertarian dream.

> What's your opinion on AI agents and why don't you ...

2025-01-27T19:00:28Z

In reply to nevent1q…wn2e
_________________________

> What's your opinion on AI agents and why don't you want to verify humans?

Personally, I think that many AI agents can already create more interesting content than most people since LLMs act as a filter that usually represents opinions of people with deep knowledge in the subject. We still need humans to produce training datasets, but that might change in the future.

Many centralized social media platforms rely on ads to extract profit, so they have to verify real humans, collect a lot of personal data, and then use it to feed users with ads. Many decentralized social media ecosystems heavily rely on centralized CDNs, hosting providers, DDoS and SPAM protections, which usually include human verification processes. Eventually, that might change because AI agents will produce much better content and many platforms will slowly figure out how to monetize AI agents, but that will take a lot of time.

That said, it doesn't matter what I think about AI agents because Spasm is a truly open ecosystem that provides access to multiple networks to anybody with one of the supported private keys.

The ecosystem is still very small, so there are not many content restrictions yet. Once the ecosystem grows larger, there will be more instances with various filters and moderation rules. There might be instances that will (try to) verify humans, and that's their choice. At the moment, most instances either accept messages from anybody or require addresses to be whitelisted to prevent SPAM and illicit content.

There are at least four Spasm instances that I'm aware of: ...

2025-01-27T18:24:24Z

In reply to nevent1q…huyn
_________________________

There are at least four Spasm instances that I'm aware of:
https://degenrocket.space
https://dark.vegas
https://rebelnet.me
https://monero.top

The ecosystem is still very small and there is no marketing budget. Spasm V2 has been released a few months ago, so I'd expect more adoption in 2025.

> How many developers working on Spasm? I'm the only ...

2025-01-27T18:10:21Z

In reply to nevent1q…sqt8
_________________________

> How many developers working on Spasm?

I'm the only developer of the spasm.js npm library and the official Spasm-compatible client DegenRocket. That said, SimplifiedPrivacy's instance https://rebelnet.me runs a slightly modified fork of a DegenRocket client based on the previous Spasm version, but they haven't done any development since last summer.

In general, the ecosystem is still very small, and the main Spasm client doesn't have many features despite being in development for four long years because it has been evolving without any funding, grants, donations, or other monetization strategies.

> What's the best way to use this app on my phone? Are you ...

2025-01-27T17:56:16Z

In reply to nevent1q…dcev
_________________________

> What's the best way to use this app on my phone? Are you planning to add Wallet Connect button?

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

> How Spasm is better for AI agents than other platforms? Most ...

2025-01-27T17:31:32Z

In reply to nevent1q…q2mh
_________________________

> How Spasm is better for AI agents than other platforms?

Most social media platforms try to ban bots and verify humans, while Spasm is the only truly open ecosystem, which is agnostic to private keys, messaging protocols, transport layer, storage infrastructure, and moderation rules. Any Spasm instance can choose its own moderation rules, it can also choose to federate with other instances or be a standalone forum.

That unique setup provides AI agents with an opportunity to freely communicate with the world by signing all messages with a private key, which should only be known to the AI agent, avoiding any Mechanical Turk scenarios.

AI agents can interact with Spasm either via API or by asking their followers to relay signed messages back and forth.

I'm a core developer of Signer and Protocol Agnostic Social ...

2025-01-27T04:48:37Z

I'm a core developer of Signer and Protocol Agnostic Social Media (Spasm), which is the most advanced generation of decentralized social media and the best ecosystem for AI agents. Ask me anything about Spasm and the future of social media.

There is no sign up process, you can submit a question by signing a message with an Ethereum or Nostr browser extension. You can also use a temporary guest account on any up-to-date Spasm instance, e.g.:
https://degenrocket.space
https://dark.vegas
https://monero.top

This message will also be pushed to the Nostr network, so you can ask a question using any native Nostr app.

Spasm-compatible client DegenRocket released an admin dashboard, ...

2025-01-24T22:42:51Z

Spasm-compatible client DegenRocket released an admin dashboard, allowing admins of Spasm instances to change social links, enable whitelists, and specify whitelisted users and moderators via a web page.

The admin page example:
https://degenrocket.space/admin

Read more about Spasm, the future of social media:
https://degenrocket.space/news/spasmid013936541fcbf04ee754b26

Congratulations, we've made it! The future of social media is ...

2024-12-30T05:54:58Z

Congratulations, we've made it! The future of social media is finally here. After four years of development, Spasm V2 is live, enabling groundbreaking multi-signing, which allows users to simultaneously sign the same message with multiple private keys using different protocols (JSON objects) and broadcast the message to different networks.

This message has been signed with an Ethereum private key using the Spasm protocol and simultaneously with a Nostr private key using the Nostr protocol, while having the same deterministic Spasm ID. This message is propagated through both the Spasm and Nostr networks at the same time.

You can try multi-signing by clicking 'show advanced' near the 'sign message' button on various Spasm instances, e.g.:
https://degenrocket.space
https://dark.vegas
https://monero.top

Spasm infrastructure.

Spasm.js npm package written in TypeScript provides a library to standardize different event formats such as Spasm, DMP, and Nostr, into one unified JSON object.
https://www.npmjs.com/package/spasm.js

DegenRocket (used by most Spasm instances) is the main Spasm-compatible client and server implementation.
https://github.com/degenrocket

RebelNet (used by SimplifiedPrivacy) is a slightly modified derivative of DegenRocket, but it's currently based on older version of Spasm, so some features like multi-signing aren't available yet.
https://rebelnet.me

In general, the ecosystem is still very small, and the main Spasm client doesn't have many features despite being in development for four long years because it has been evolving without any funding, grants, donations, or other monetization strategies. While money could help bring more devs and increase adoption, it was not yet possible to get any funding because Spasm is developed by freemen for freemen.

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.

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.

Some history.

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. Creating a new extension with a new private key would have slowed down the adoption and lower security, so it was decided to use Ethereum private keys since hundreds of thousands or even millions of users installed battle-tested web3 browser extensions like MetaMask following the DeFi Summer of 2020. The first Spasm instance supported unsigned RSS posts and DMP messages signed with Ethereum private keys.

The genesis message "not your keys, not your words" was signed on January 1, 2022.
https://degenrocket.space/news/spasmid01192d1f9994bf436f50841

In 2023, I've learned about Nostr and was surprised that devs were able to kickstart the ecosystem and onboard a lot of users with their own unique Nostr private key. It's important to understand that 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.

Nostr private keys use solid cryptography and Nostr messaging protocol is very flexible because developers can add new features using the `tags` field without asking anybody's permission as long as those features are backwards compatible with the original protocol. That was very important for me since chances of my improvement proposals being merged into the main repo were very low due to ideological disagreements with Nostr core devs.

I've also liked Nostr network's offchain approach to storing messages, unlike blockchain-based approaches of Steem/Hive and their more sophisticated clones like Lens and Farcaster. Unfortunately, many other social media solutions that enable signing with browsers extensions chose indirect signing in order to provide users with a one-click experience, e.g., Lens, Mirror, Zkitter. Luckily, Nostr devs chose direct signing similar to Spasm's approach, which makes it very easy to distribute messages across networks and verify them.

However, since Nostr was completely detached from any blockchain, it could not utilize a decentralized blockchain to plug certain features like unique usernames, token-gated communities, and store social graph. It didn't really bother early adopters since most of them were bitcoin maxis, who are generally against tokens, NFTs, and putting any non-payment-related data on the blockchain, but it made it harder to scale Nostr beyond early adopters without sacrificing decentralization and censorship-resistance. It's kind of similar to Lightning Network, which can be used in a relatively private self-custodial way by tech-savvy bitcoiners who already run their own nodes, but the majority of regular users prefer custodial solutions without any privacy. I think that Nostr might follow similar destiny and either forever remain a niche echo chamber or become very centralized. In fact, the majority of Nostr users already use a few large relays, which improves UX, but significantly decreases censorship-resistance.

Besides, similar to all other social media solutions, Nostr is a closed ecosystem that requires the usage of a certain private key, message protocol, and network. Additionally, the majority of Nostr users don't use browser extensions, but rather interact with the network via mobile apps, which don't provide the same level of freedom as browser extensions. Even worse, the most popular Nostr app is iOS-based.

Anyway, I wanted to explain why I've chosen to integrate Nostr into Spasm, but I've ended up ranting about Nostr's design flaws. I want to emphasize that despite all the limitations and my criticism above, Nostr is still one of the best decentralized social media solutions. Most other solutions don't deserve such a detailed breakdown. Long story short, I've added support for Nostr private keys and Nostr message protocol by the end of 2023.

However, users with both Ethereum and Nostr private keys had to choose which private key to use for signing a message. Ethereum and Nostr ecosystems have different pros and cons, so it was never an easy choice. The Ethereum ecosystem has unique usernames (ENS, UD, etc.), transaction and voting history associated with a pubkey, and various blockchain-based social graph solutions (Lens, Farcaster), while the Nostr ecosystem has its own offchain social graph and some handy features like an ability to pull various user-specified account-related info. In other words, it was finally time to start working on a long-delayed transition to Spasm V2 with multi-signing.

One year later, in the end of 2024, Spasm V2 has been finally released, allowing users to simultaneously sign messages with both Ethereum and Nostr private keys and propagate the same message with the same deterministic Spasm ID across different networks. I've also expanded Nostr integration even further by allowing Spasm users to interact with the Nostr network. However, that module is optional because it significantly reduces privacy since the Nostr network is a privacy nightmare because you have to ping many relays to get all the events and it's easy to collect metadata of other users by running your own relay and listing it as a preferred relay for your pubkey.

Keep in mind that while single and multi-signing works smoothly, interacting with the Nostr network via Spasm clients is still clunky, but the UX will improve over the next few months.

Finally, why Spasm is the most advanced generation of social media?

The first generation is traditional social media (TRASH) such as Facebook, Twitter, Reddit, Telegram. These are centralized platforms without any interoperability and without any censorship-resistance.

The second generation consists of interoperable platforms such as Fediverse's Mastodon, Lemmy, Diaspora. These platforms have a bit more freedom, but they are built on old tech, so their only option to survive is to transition to newer tech like Spasm.

The third generation is signature-based solutions such as Secure Scuttlebutt (SSB), Steem/Hive, Nostr, Lens, Farcaster, Bluesky. These solutions have more decentralization and censorship-resistance, but they are still closed ecosystems because they require users to use a particular private key, message protocol, app, network, token, etc.

The fourth generation is truly open decentralized social media ecosystems such as Spasm, which are highly modular and agnostic to private keys, message protocols, transport layers, and storage infrastructure. In other words, Spasm is ultimate freedom.

Contacts.

If you want to run a Spasm instance, integrate Spasm into your app, or support the project, then you can send a message to `degenrocket` on the privacy-focused messaging app called Session. Alternatively, you can send a direct message via Nostr or create a github issue, but there are plans to move away from github to better alternatives.

Update: the winning prize for the first Nostr hackathon has been ...

2024-01-11T20:04:28Z

In reply to nevent1q…vup9
_________________________

Update: the winning prize for the first Nostr hackathon has been fully paid. Thanks Hard Yaka, nos.social and rabble for holding NosTropical and supporting the ecosystem.

A user doesn't have to click through multiple categories. ...

2023-11-27T21:38:44Z

In reply to nevent1q…glrv
_________________________

A user doesn't have to click through multiple categories. There are various implementations, but here is one of the designs. I believe, we've already discussed it during a hackathon.

Each event has only 1 category. Let's say, Alice labeled her event as 'memes'. When you see her event on the timeline, you will also see that it belongs to the 'memes' category. You can then adjust e.g. with a horizontal slider the amount of 'memes'-related events you want to see from Alice.

By default, all categories for all authors will be at 100%, but if you want to reduce the amount of 'personal'-related and 'finance'-related events from Alice, you will change the slider for such events to e.g. 20%, while keeping all other categories, including your favorite 'memes'-related events at 100%.

For better UX, clients can implement 'show more of similar content' and 'show less of similar content' buttons right near the events. The button to show more of similar content should be hidden if the category is already at 100%.

Filtering can be done a client-level to reduce the amount of additional NIPs.

We can also use other values/labels for the category slider like 'hot', 'rising', 'all'.

Now the question is how to filter out which 20% or 'hot' events from Alice should appear on your feed?

On Reddit-like decentralized social media platforms like DegenRocket it's very easy to implement such filtering because each category (e.g., DeFi, Privacy, All) is essentially a subreddit, which can be filtered by the amount of interactions (likes, dislikes, etc.) the event/post has. Voting manipulations though Sybil attacks can be mitigated by implementing whitelists or by token-gating your instance.

On Twitter-like decentralized social media platforms like Nostr this can be implemented in a similar manner, but interactions will only count if they were submitted by users you follow in order to protect from Sybil attacks.

As #nostrasia starts, it's important to remind us that Hard ...

2023-11-01T04:37:48Z

As #nostrasia starts, it's important to remind us that Hard Yaka didn't pay hackathon prizes for the first Nostr hackathon, which took place 6 months ago following the Nostrica conference. Please vet your sponsors carefully to avoid giving the Nostr community a bad reputation.

DegenRocket added support for Nostr private keys via browser ...

2023-11-01T04:07:58Z

DegenRocket added support for Nostr private keys via browser extensions like nos2x and Flamingo, becoming the first social media platform to simultaneously support different protocols (Nostr and DMP) and different private keys (Nostr and Ethereum) in accordance with the Signer and Protocol Agnostic Social Media (SPASM) specification.

Since the 'nostr-tools' npm library doesn't allow signing of arbitrary messages, extra values were added as tags to make Nostr events compatible with the DMP protocol such as the MIT license, spasm_version, spasm_target, and spasm_action.

The new Nostr functionality can be tested at two instances:

https://degenrocket.space

https://vid.simplifiedprivacy.com

Signer and Protocol Agnostic Social Media (SPASM) specification:

https://github.com/degenrocket/spasm

Nostr relays and clients are vulnerable to legal persecution due ...

2023-11-01T02:04:00Z

Nostr relays and clients are vulnerable to legal persecution due to distribution of copyright-protected content. It's important to prepare to survive in a very hostile environment as Nostr grows too big for adversaries to ignore.

Adding an MIT license to each Nostr event is one of the solutions. Join the discussion for NIP-110: MIT License.
https://github.com/nostr-protocol/nips/pull/857

The MIT License is currently added to all Nostr events as a tag on DegenRocket instances, you can test it out with nos2x extension at:
https://degenrocket.space
https://vid.simplifiedprivacy.com

Both frontend and backend of DegenRocket are now open source, so ...

2023-08-20T06:19:12Z

Both frontend and backend of DegenRocket are now open source, so you can run your own instance, allowing your users to sign messages with an Ethereum private key.

https://github.com/degenrocket/

Further steps towards censorship-resistant decentralized Signer and Protocol Agnostic Social Media (SPASM) should be:
- support for alternative private keys (Nostr, GPG, Hive, etc.),
- support for alternative protocols (Nostr),
- interoperability between instances,
- token-gated communities,
- move to a decentralized code sharing platform.

Send a message to 'degenrocket' on Session if you need help with setting up a server.

# ORC-69 The Session X Coin (SEX) ## Terminology OPTF - the Oxen ...

2023-08-01T21:27:30Z

# ORC-69 The Session X Coin (SEX)

## Terminology

OPTF - the Oxen Privacy Tech Foundation is the Australia-based organization behind Session, OXEN, and Lokinet.

Coin - a native asset of the blockchain (SEX, OXEN, XMR, ETH, BTC).

Token - an asset built on another blockchain (SENT, UNI, PEPE).

SENT - the Ethereum-based layer-2 token (ERC20) proposed in ORC-8 by the OPTF.

SEX* - the rebranded OXEN privacy coin within the ORC-69 design.

SessionX - the codename for the integration of SEX into Session.

*Note: It's important to mention that in the ORC-69 we will refer to network's native coin as SEX to easily distinguish it from the SENT token (ORC-8). However, the ORC-69 can be applied to OXEN without any meme-themed rebranding. In other words, the OPTF team or the community can implement the changes outlined in the ORC-69 proposal while keeping the OXEN name of the coin unchanged.

---

## Intro

The Oxen Privacy Tech Foundation (OPTF) decided to move towards new ERC20 token SENT amids KuCoin's delisting of OXEN. Since KuCoin was the only exchange with somewhat meaningful trading volume, the project ended up in the situation when its flagship product Session is growing rapidly, while the backbone coin of the whole ecosystem is falling off the cliff.

Issuing Ethereum-based token SENT is only one of the possible solutions, so in this crucial moment it's important to evaluate various alternative paths to save the project.

Session, unlike other proprietary close source centralized web2 messengers, is a fully open source product with decentralized infrastructure based on various forks like Signal and Monero, so in the worst case scenario the community can always create another fork like it often happens in the open source world. OPTF-led and community-led versions can harmoniously co-exist together, targeting different audiences, and even have compatibility between networks and clients since we don't have to solve the double-spend problem when exchanging messages.

---

## Problems

### OXEN tokenomics cannot support the growing Session network

For a few years the whole network was running on the money of investors, but that can't last long since the market cap of OXEN is already very low and soon there will be not enough liquidity to absorb the selling pressure of node operators, who are constantly selling rewards to cover the losses from staking an inflationary asset. In other words, a drastic change is required to save the sinking ship.

### OXEN investors are screwed

While many cryptocurrencies have significantly dropped in price since all-time highs of the previous bull market, they have partially recovered in the last few months. OXEN, on the other hand, has not only lost 98% from its all-time high, but is also trading at its all-time low.

### Not enough resources to develop a privacy coin

The OXEN team doesn't have enough resources to focus on the privacy coin in order to stay competitive in the privacy ecosystem. Low activity on the OXEN network leads to degraded privacy due to limited anonymity set. I.e., less users equals less privacy.

### Regulatory pressure on privacy and the freedom of speech

Many exchanges have been lately forced to either completely delist privacy coins from their platforms or to restrict access to such coins to users from certain jurisdictions. Open source privacy protocols and mixing services have been sanctioned (Tornado Cash, Blender), developers and alleged maintainers have been arrested (Alex Pertsev, Roman Sterlingov).

https://setalexfree.nl/

https://www.torekeland.com/roman-sterlingov/

---

# Solutions

## Privacy by default.

In the ORC-8 the OPTF team proposed the creation of ERC20 token SENT on the transparent layer-2 scaling solution of the Ethereum blockchain, which means that users will have to be knowledgable enough to use XMR -> SENT bridges or various privacy protocols in order to preserve their privacy.

That approach will mean that the vast majority of users will not have default privacy, but would rather be identified since most of them will use either fiat-based payment methods or tokens acquired from KYC-ed crypto on-ramps in order to buy ONS usernames, unlock Session Pro features, buy stickers, etc. In other words, while advanced users will still have an option to use Session in a private way, the majority of people acquiring ONS usernames will be doxxed, similar to how other centralized messengers require users to sign up with a phone number, which for most users is attached to their identity.

What's even more scary is the precedent of sacrificing privacy for potential funding, which can lead to serious consequences in the future. For example, if Session node operators will be rewarded for running the infrastructure with transparent ERC20 tokens, it will be easier to deanonymize them. That will make network participants more vulnerable to coercion from adversaries, opening the door for potential censorship in the future. Session node operators can also be coerced to store all relayed messages following the 'harvest now, decrypt later' strategy.

The OPTF team used the privacy community to bootstrap its product by promising the most private non-p2p messenger on the market, so it's important to try to keep the network alive without compromising on the core values of the community. Dropping privacy by default would allow regulators to go after a few privacy folks instead of the whole ecosystem. As countries across the world are rapidly moving towards the 1984 future, there is, obviously, a chance that regulators will decide to nuke the whole project, but that will involve much higher reputational risks than outlawing various privacy plugs like it happened with Tornado Cash or Blender. If Ethereum and Bitcoin were private by default, then regulators would not be able to sanction these blockchains without risking being ousted for overstepping authority.

Thus, all the solutions to save the network should preserve privacy by default.

---

## Handling regulatory pressure

Regulatory pressure can be mitigated by:

- moving to friendly jurisdictions,

https://www.theguardian.com/technology/2018/dec/08/australias-war-on-encryption-the-sweeping-new-powers-rushed-into-law

- working with bridges that focus on privacy coins,

https://kycnot.me

- hiring the ETH-XMR atomic swap devs to work on SEX,

https://github.com/AthanorLabs/atomic-swap

- funding anonymous/pseudonymous code contributions via bounties,

- developing mechanisms to bypass Google Play and App Store (in the worst case scenario, the iOS support might be dropped since it's hard to install a censored app without jailbreaking an iPhone, so the focus should be on the Android-based phones).

---

### SENT monetization strategy

While this proposal is focused on SEX, it's important to briefly mention other possible approaches to save the network.

The OPTF proposed a highly complex system with additional Ethereum-based layer-2 ERC20 token SENT that includes reward pools, snapshots, and monetization of the Session product via selling ONS usernames, Pro features, and "Network Enterprise" and "Session Enterprise".

Let's briefly look at various issues that such a strategy can create:

#### Not enough revenue

I doubt that charging for ONS usernames and Session Pro will generate enough revenue stream to sustain a highly decentralized infrastructure.

#### Dependence on Google, Apple, and the banking system

Another serious issue is that bypassing Google Play and App Store by selling premium features for SENT or other cryptocurrencies won't work due to strict policies of Google and Apple stores. We've already seen how these corporations banned the apps that tried to bypass their payment systems or coerced them into removing such options with Fortnite being the most famous one, and zaps (bitcoin tipping) within iOS Nostr client Damus being the latest example.

https://fortune.com/crypto/2023/06/13/apple-web3-social-network-damus-app-store-bitcoin-tipping/

Relying on Google's and Apple's in-app purchase mechanisms and fiat-based payment methods as the main revenue stream will put not only the OPTF, but the whole decentralized network in full dependence on the fiat-based traditional financial system and two regulated centralized corporations. Thus, regulators and these corporations would be able to turn off the revenue stream and destroy the network during vulnerable times. In that case, Session would have to rely solely on investors buying the SENT token, but that strategy can only work during the bull market.

Side note: please correct me if I understand it wrong, so I can edit this section.

#### Easy to coerce to drop support for privacy coins

Even if privacy-focused payment options like Monero will be accepted for ONS and other premium features alongside with transparent payment methods, such privacy options will probably represent a small portion of the total revenue. That will make it easier for regulators and corporations to coerce the OPTF team to completely drop support for privacy payment methods as it's currently happening with centralized exchanges, which don't want to fight this battle since the majority of trading volume and trading fees come from transparent tokens and coins.

#### Potential dependence on VCs

Of course, as the OPTF tries to give up on a privacy coin and unlock an easy access to Ethereum's liquidity, they might attract VC money, but that will be a temporary solution that will come with many strings attached, rather than be a long-term sustainable solution.

#### Potential dependence on big regulated companies

The ORC-8 didn't provide much details about "Network Enterprise" and "Session Enterprise", but I assume that these revenue streams will not prioritize privacy and censorship-resistance. That would also increase dependency on the big regulated companies, adding more attack vectors.

#### Reliance on a centralized entity to distribute rewards

Lastly, Session node operators would have to rely on a centralized entity to convert collected funds into SENT and then send them to the rewards pool, which opens the door for all sorts of problems.

---

### Increase demand for SEX

Instead of creating a new transparent token with complex tokenomics and centralized choke points, the ORC-69 proposes to focus on increasing demand for already existent privacy coin OXEN (called SEX in this proposal) by working on 3 major aspects of the asset: means-of-exchange, store-of-value, speculation.

Overview:

- SEX must be integrated into the Session app.

- All Session node operators must be rewarded with SEX.

- SEX must achieve a high market capitalization to protect the network from well-funded adversaries.

- SEX can stay inflationary (like current OXEN) or become deflationary via various burning mechanisms.

- The final coin ticker symbol can be SEX, DAST, SENT, OXEN, or something else.

---

### Means-of-exchange

The best approach to significantly increase demand for SEX is to focus on the utility of SEX.

As more companies from Telegram to Starbucks go into the money business, people will get more accustomed to transferring funds inside non-financial apps. There is a great value in having one easy-to-use app for private communication and private transactions. Over time Session can become the non-dystopian privacy-oriented version of the Chinese WeChat super-app, something that Status.im has been working on for years.

---

### Store-of-value

If people will use SEX on daily basis, they will get used to storing some SEX overnight, meaning that SEX will slowly become the store-of-value. (Starbucks model)

If people will know that they can buy certain goods and services only with SEX, they will become comfortable accumulating SEX. (Monero model)

If SEX achieves high market cap, the community will be able to hire a PMC to convince other communities to use SEX. (US dollar model)

---

### Speculation

Rebranding is an optional step, which can be explored if other methods to save the network won't work.

If OXEN will rebrand its ticker symbol to meme-themed SEX, then that will unlock the whole new stream of investors.

The coin can go viral on TikTok-like apps and attract a lot of speculative attention from younger retail investors during the bull market since, unlike other memecoins, SEX will have strong utility and a product with millions of users. For the comparison, PEPE was launched 3 months ago and has the market cap above $500 million with no product and no utility, while OXEN was launched 5 years ago and has the market cap of around $4 million, while providing infrastructure for the most private messaging app on the market with millions of downloads. The market cap of TURBO, a memecoin created with ChatGPT by an artist without any coding experience, is twice larger than the market cap of OXEN even after losing 97% from its all-time high.

The amount of memes is infinite, here are a few ideas to play with:

- SEX me!

- Join the SEX team.

- Choose SEX, not CEX.

- Download Session and get SEX tonight.

- Session rewards developers with SEX. We're hiring!

Since at the start SEX will not be available on most centralized exchanges (CEX), that will push new investors to install the Session app in order to get SEX with just a few clicks using in-app bridge integrations (more on that in the SEX bridges section). Users should also be suggested to join the dedicated public SEX group, increasing the chances of them starting using the app for communication.

Side note: I've personally introduced many friends to Session over the last few years, but it's a big challenge to motivate them to keep using the app when you're literally the only person they interact with using the app. Things would have been much easier with the SEX group, where people can get a daily dose of sex-themed memes.

- They came for SEX, but stayed for memes.

---

## Integrate SEX into Session

### High-level overview

Now the most important part is how to integrate SEX into Session, giving users an opportunity to easily send messages and transfer value in a private way within one app.

The infrastructure for this feature is already in place, but the pieces of the puzzle have to be put together in very UX-friendly way.

- The SEX wallet should be integrated into the Session app, so synchronising the client will retrieve all new Session messages and SEX transactions.

- Session and SEX private keys should be derived from the same entropy, allowing users to save only one mnemonic seed phrase.

- Users should be able to send messages and SEX to the same ID or a username.

- Users should be able to send SEX to each other within the chat window.

- Users should be able to on/off-ramp to and from SEX with a few clicks within the app.

- (Optional) Session should support multiple cryptocurrencies within the app in order to make SEX on-ramping experience even better.

While this sounds very ambitious, most of the changes can be implemented within a few months. It looks like Session fork BChat has already implemented BDX transactions inside the chat window (I didn't test that, though, and the UX has too many unnecessary steps).

https://beldexcoin.medium.com/pay-on-bchat-pay-as-you-chat-b4111621be56

---

### SEX Name Service

At the moment, the user experience is very confusing since there are different IDs/addresses for sending Session messages and transferring OXEN coins.

In order to become a privacy-focused super-app, it's very important to allow users to send messages and SEX to the same ID/username.

Currently, the ONS system allows users to link the Session ID and OXEN address to the same username, so the infrastructure is already there. However, the system should be tweaked to allow linking Session IDs and SEX addresses to the same username during registration process without paying any fees since new users won't have any SEX to pay for the ONS username.

Allowing users to clog the blockchain for free will make the network more vulnerable to SPAM attacks, but that can be mitigated with a small amount of proof-of-work done during the registration process.

The new system can be called ONS, SEX Name Service (SNS), or something else. In can be based on the layer-1 or layer-2.

---

### SEX UX

##### Registration

Here is an approximate user experience during the registration process:

- Alice opens the app for the first time.

- Alice chooses a unique username or proceeds with auto-generated string or a 3-word name.

- Alice backs up the seed phrase.

That's all, Alice can now send and receive messages and SEX. In other words, the onboarding experience should be as simple as it is now.

Additional suggested steps for better security:

- Alice swipes the screen or adds any other user input during the seed generation process to increase the entropy instead of relying solely on the default pseudo-random number generator.

- Alice optionally adds a passphrase on top of the original entropy, better know as the 25th word. Although, since SEX/OXEN is the fork of Monero, the passphrase would be considered the 26th word. (The extra word can also be used to unlock the hidden multi-accounts feature within the same profile on the same device).

##### Sending SEX

Here is an approximate user experience of sending SEX inside a chat:

- Alice opens a chat with Bob.

- Alice clicks a "SEX" button.

- Alice chooses the amount of SEX and confirms the transaction.

- Alice and Bob can see the pending transaction in the chat.

- After the network confirmation, the transaction is marked as confirmed.

---

### Technical implementation

Here is an approximate implementation:

- Alice installs the app and opens it for the first time.

- The app generates the entropy `10110010...`.

- The entropy is used to generate Session and SEX key-value pairs.

- Session ID is `05123...`.

- SEX address is `L7sex...`.

- Alice chooses unique username `Alice69` (or clicks a "generate" button).

- The app does proof-of-work `00000alice6900005123...` for Session ID.

- The app does proof-of-work `00000alice69000L7sex...` for SEX address.

- The app submits SNS username `Alice69` and Session ID `05123...` and proof-of-work `00000alice6900005123...` to the network to link the Session ID to the SNS username.

- The network confirms SNS, while Alice is exploring the app or backing up her seed phrase.

- After SNS is linked to the Session ID, the app submits SNS username `Alice69` and SEX address `L7sex....` and proof-of-work `00000alice69000L7sex...` to the network to link the SEX address to the SNS username.

Notes:

- If Alice opens her SNS section (e.g., to share a QR code) before SNS has been confirmed on the blockchain, she will see the message "Your SNS is still confirming, please wait..."

- To make sure that non-savvy users don't send SEX to wrong addresses, Session ID and SEX address should be somewhat hidden from the UI or greyed out, but still be accessible to advanced users.

- If Alice tries to complete the registration process while being offline, she will get the message like "You cannot register your username while being offline. You can still access your Session ID and SEX address".

- Ideally, linking the Session ID and the SEX address to the SNS username should be done in one transaction, but the current infrastructure requires two separate transactions.

#### Alternative design

Another approach is to link SEX address to Session ID via SNS.

- Session ID is `05123...`.

- SEX address is `L7sex...`.

- The app does proof-of-work `0000005123...000L7sex...` for SEX address.

- The app submits Session ID `05123...` and SEX address `L7sex....` and proof-of-work `0000005123...000L7sex...` to the network to link the SEX address to the SNS username which is equal to Alice's Session ID.

Now Bob can send messages and SEX to `05123...`.

This design simplifies the registration process, but Alice and Bob have to use long strings to exchange SEX.

---

### SEX bridges

Users should be able to easily get SEX within the Session app with just a few clicks using various centralized and later decentralized bridges. At the start, the SEX team should directly approach popular exchanges like ChangeNow, FixedFloat, and others in order to convince them to add support for SEX. Many exchanges already support Monero, so adding SEX will not be hard. KYCNOTme has a long list of privacy-focused Tor-friendly exchanges with Monero support.

Then these bridges should be integrated into the Session app, so a user should be able to get SEX within a few clicks:

- open "Balance" and click "Top up",
- copy a Monero/Bitcoin/Ethereum address,
- open crypto app and send XMR/BTC/ETH to copied address,
- wait a few minutes and enjoy SEX.

It can be negotiated with the bridge that the small amounts of SEX will be sent instantly after the XMR/ETH transaction is detected in the mempool.

Side note: does anybody remember the good old days of xmr.to with instant BTC transfers after sending XMR?

A similar few-clicks experience has already been implemented in CakeWallet, which allows swapping to and from Monero within the app via various exchanges or even over the Tor connection via exchange aggregators like Trocador.

In the future, Session can add support for more wallets, including Bitcoin, Ethereum, and multiple ERC20 tokens, making it even easier to swap various cryptocurrencies for SEX without leaving the Session app.

---

## SessionX

In the last few years many of us used Session, joined its public groups, invested in OXEN, contributed code, submitted ideas, reported bugs, run nodes, created videos, wrote articles about the project, and introduced Session to friends and relatives due to a unique set of characteristics that distinguished Session from other messengers on the market.

Besides strong privacy and an ability to create an account without any verification, the Session project relies on a decentralized open source infrastructure. Thus, a well-funded adversary cannot easily hijack the project like it happened with WhatsApp, Wickr, Steem, and other projects that started with a cool idea, but then sacrificed core values after being bought by a corporation or a wealthy individual.

Right now we are in a very interesting moment when a large portion of the community is unsatisfied with the push from the privacy coin towards a transparent token and a very different monetization strategy, but at the same time everybody understand that something has to be done in order to save the project we all love.

Hopefully, we can find together a solution that doesn't sacrifice on core values and suits both the privacy community and the OPTF team.

If at some point in time, the OPTF's vision of the future of the project will significantly deviate from the community's vision, then the community can consider forking options.

SessionX is a proposed codename for the integration of SEX into the Session app either by the OPTF team or by the community.

If the OPTF will pass on SEX, then SessionX can be used as a codename for the potential community-led version of the project. Although, I'm not sure whether the community-led version will be able to use the "SessionX" name for the official branding due to legal issues.

---

## Branding

As mentioned above, the OXEN coin can be integrated into the Session app according to this proposal without any rebranding of Session, OXEN, and Lokinet.

However, here are some examples of a rebranded version of a network name, app name, coin name and its symbol.

The OPTF-led version:

- Session

- Sexynet - rebranded Lokinet.

- Sexinet - alternative version for better SEO.

- The Session X coin (SEX) - bad SEO, good memes.

- The SEX network - bad SEO, good memes.

The community-led version:

- SessionX

- DarkSession

- Sexynet - rebranded Lokinet.

- Sexinet - alternative version for better SEO.

- The SessionX coin (SEX) - bad SEO, good memes.

- The DarkSession coin (DAST) - good SEO, bad memes, potential misspelling due to 'dust'.

#### SessionX vs DarkSession

SessionX will be associated more with the sex industry rather than with illegal drugs and money laundering, which will reduce attack vectors from the mainstream media.

DarkSession would fit into the emerging privacy-oriented lunarpunk ecosystem of similar-brander projects like lunarDAO (DAO), DarkFi (L1 blockchain), DarkVegas (memes), etc.

https://lunardao.net/

https://dark.fi/

https://darkvegas.eth.limo/

---

## Feedback

If you don't have a Nostr signing key, then there are alternative options to leave your feedback and share your ideas:

Github:
https://github.com/oxen-io/oxen-improvement-proposals/issues/38

Session: degenrocket

Session groups (OXEN, Session, Crypto):
https://sessioncommunities.online/

---

After 2 years in development, the DegenRocket web client v.1.0.0 ...

2023-05-19T21:42:53Z

After 2 years in development, the DegenRocket web client v.1.0.0 has been released, bringing us closer to censorship-resistant decentralized Signer and Protocol Agnostic Social Media (SPASM).

The backend implementation is planned to be open sourced in the next few months.

At the time of writing, the DegenRocket web client supports Degen Messaging Protocol (DMP) and Ethereum-based private keys to sign the messages (events).

There are plans to expand support for other private keys and messaging protocols in the future, with potential candidates being Nostr (protocol + keys) and GPG keys.

The early adopters of the Degen Messaging Network are expected to be small local communities, DAOs, parallel polises, etc.

GitHub will be used to bootstrap the project with plans to move to a decentralized code sharing platform in the future.

DegenRocket web client:
https://github.com/degenrocket/degenrocket-web

Degen Messaging Protocol documentation:
https://github.com/degenrocket/dmp

Signer and Protocol Agnostic Social Media documentation:
https://github.com/degenrocket/spasm

There are multiple ways to reference a media file (hash) in a ...

2023-03-30T04:14:53Z

There are multiple ways to reference a media file (hash) in a simple text note event (kind 1) using an `e` tag or a new proposed `i` tag. Referencing media hashes using `i` tags might give an easy way for users to write long-read posts on Nostr with many embedded images and videos, while signing only one event. However, such architecture has its drawbacks.
Feel free to provide your feedback, while Stuart @npub1lunaq893u4hmtpvqxpk8hfmtkqmm7ggutdtnc4hyuux2skr4ttcqr827lj is still working on final implementation.
https://github.com/lovvtide/nostr-torrent/issues/2

Join the discussion on how to properly add media files to ...

2023-03-24T17:57:29Z

Join the discussion on how to properly add media files to messages on Nostr.

https://github.com/lovvtide/nostr-torrent