> 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 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:
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 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 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 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 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.:
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, 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 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.:
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.
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 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. 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 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 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://vid.simplifiedprivacy.com
Signer and Protocol Agnostic Social Media (SPASM) specification:
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:
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 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://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,
- working with bridges that focus on privacy coins,
- 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.
---
## 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 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:
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.
Join the discussion on how to properly add media files to messages on Nostr.