There are several options to roll out RLN in the Status app. This post aims to provide clarity on current plans and options, and initiate discussions for future plans.
Context
Feel free to skip directly to planned work if you are already familiar with the current situation.
In traditional chat application, all messages go through a central infrastructure. This infrastructure can rate limit inbound messages to protect the infrastructure itself, as well as users.
In a permissionless peer-to-peer network such as Waku, no such entity can be introduced. Meaning without protection, users and infrastructure may need to handle a volume of traffic higher than what their resources can cope. Bandwidth is the primary limiting factor, but processing, memory and battery can also be exhausted.
Opt-in message signing
A temporary solution was done to provide some DoS protection while RLN was being developed: opt-in message signing.
In this solution, a pre-shared private key is distributed to all network participants:
- publishers sign their messages with this key on the routing layer
- relayers verify the signature against the matching public key
If a publisher sends a message without the right signature, the message gets drop by the routing layer. In Status’ context, it is used as follows:
- common shards (1:1 messages, request to join community, etc) are protected by a an app key, embedded at build time
- Shards dedicated to a community are protected by a key generated at community creation time, and distributed to members when they join
This comes with a number of caveats:
- No rate limit is being applied, meaning no capping on resources (e.g. bandwidth).
- Difficult handling of kick/ban of users (key rotation is a difficult problem when used for gossipsub validation)
- High risk of the pre-shared key being compromised:
i. every user get same key
ii. app key can extract via reverse engineering
and again, hard problem to rotate keys - Not actually permissionless: users can only use official app build, can’t build own app
RLN
RLN solves the drawbacks above:
- RLN applies a rate limit to publishers, capping the number of messages that can be send on the network.
- Insertion and deletion of membership is straightforward and handled by a smart contract
- Main security risk is for individual member to leak their RLN credentials. One user cannot compromise the whole system. No app key. Again, memberships can easily be managed on the smart contract.
- Permissionless: the deployed smart contract dictates the rules to join
Planned work
RLN Mainnet
The roadmap to deploy RLN on mainnet will soon be published.
The intent is deploy RLN on a L2, testnet and then mainnet. Preferably on Status L2 but if not ready in time, we will aim to use Linea.
The new contract will be used to protect The Waku Network (we currently use a sepoliia smart contract with no membership insertion fees).
This will allow further experimentation and for external projects to use a mature version of RLN.
Nwaku integration
To avoid continuing with the duplicate effort of maintaining go-waku and nwaku. A line in the sand has been drawn to RLN in terms of go-waku support.
The integration of nwaku in Status Desktop is resuming this month (Milestone Nwaku in Status Desktop).
RLNaaS
RLN-as-a-Service refers to light push service nodes attaching RLN proof for light clients.
RLNaaS is currently deployed on The Waku Network. We are using RLNaaS for incentivization R&D as it is a simple service, allowing a focus on the incentivization part of the problem.
It also enables usage of The Waku Network in the browser, as latest upgrade of RLN hasn’t yet been implemented in js-waku.
However, it does have a number of risks:
- security: it shifts the DoS problem, without fully solving it. As RLNaaS service nodes may get overwhelmed and run out of RLN membership quota, potentially DoS’ing end users relying on RLNaaS
- reliability: it is uncertain how reliable this would be, specifically for light clients to discovery service nodes with an non-exhausted RLN membership
Due to those risks, we are pushing hard for js-waku to dogfood RLNaaS, and extract metrics to understand if it is a viable option. A new deliverable to track this work will soon be published.
RLN in Status - Use cases
1:1 chats and private groups
With a rate limit in place, it would ensure that app in relay mode do not get DDoS’d by a user flooding the network.
It may also have some benefits in reducing the risk of a high volume of resource consuming messages such as contact requests being injected.
RLNaaS
There some additional benefits to using RLNaaS for Status chat:
- Minimal UX/UI changes, as the user would not need to acquire a membership
- Free onboarding: it avoids RLN acquisition for a user, enabling a free usage of chat app
- Status as a customer of incentivization: enable Status to be the reference application for the first versions of the incentivization protocol.
The risks previously described for RLNaaS would still apply. It also means relying on the Status fleet more heavily. Indeed, Status Desktop apps do act as light push service nodes at the moment. This would not be an option with RLNaaS; unless Status Desktop user acquires an RLN membership and attaches proof, which would negate the first benefit.
You can read more about the need of friction in Cost related to Waku infrastructure - Messenger - Status.app
RLN for end users
The end goal is for end users to acquire RLN memberships to send messages.
While this would involve more UX/UI work, it is a less risky approach in term of reliability and security. This is because it is a more sovereign/permissionless approach that would rely less on Status infrastructure.
There are also a number of options described in Cost related to Waku infrastructure - Messenger - Status.app to reduce friction for the user.
Status Communities
Dedicated Shard
Note: I already described this in Optimizing Community Description .
In the dedicated shard model, each community have their own shard, not used by any other community. Note this model has a number of scalability and decentralisation limitations.
An RLN smart contract could be deployed per community. This smart contract could have specific insertion rules: only community owner can insert, or user needs to hold community tokens to insert.
An owner could also be able to remove memberships when banning a user. By setting the Maximum total rate limit of all memberships in the tree, the owner can scale their community to their needs.
Common Shards
In a common shards model, community traffic get dispatched on a common set of shards using autosharding. Traffic maybe shared between communities, but a maximum total rate limit would still apply, to ensure bandwidth usage is reasonable.
This would be a similar approach (potentially same contract) as 1:1 chats. Where members would first need to join the common RLN smart contract, before being able to join and participate in their community of choice.
In this model, there is no limitation to the number of communities that can be created, only on the total number of user at a given time (but it can be expanded with the network).
RLN in Status - Roadmap
Integration of RLN is expected in 2025. Meaning that no milestones or deliverables have yet been agreed beyond the planned work.
The initial proposal was to first deploy RLNaaS for 1:1 Chats. It would increase protection for 1:1 chats users. However, it comes with risks (as previously stated).
A close second step would be to deploy RLN for end users, to mitigate said risks.
There may be pressure in delivering this second step, depending on the DoS risks of RLNaaS vs app key.
Deploying RLN is a breaking change. In Breaking changes and roll out strategies I have described how a roll out strategy would look like. While there would be minimal UI/UX changes, a phased roll out would still be needed.
In this same post, I have reviewed how breaking changes on Communities are easier to handle. By applying new parameters to new communities only, it would be easier to roll out breaking changes. Migrating preexisting communities can be done at a later time, if necessary.
It also put the controls in the hand of the users/community owner. Which is not the case for breaking changes of 1:1 chats.
Hence, another approach to consider would be rolling out RLN to communities first.
Doing so would need the proper UI/UX update to have end users acquire a RLN membership.
The common shard model may be better to start with, as the RLN flow would only be needed for members. Community owners would not need deploy/setup a RLN contract, a common RLN contract deployed by Status/Waku would be used.
The roll out would consist in using a new set of shards for RLN-protected communities (TWN?) and have an option to create communities in said shards.
It would enable dogfooding and experimentation without impacting current users. Users excited by the feature could opt-in and help testing.
Once RLN flows are matured enough, then 1:1 chat both RLNaaS and RLN for end user could be rolled out, with high confidence that the flows work.
Ideally, the same contract could even be used. This could also reduced the usage for RLNaaS by encouraging user to acquire an RLN membership before the roll out.
Conclusion
RLN usage in Status is multi-faceted. When deciding on the action plan, various elements need to be considered: risk, security, roll out strategy, UI/UX impacts and product appetite.
In this post, we reviewed the various ways RLN can be used, and proposed 2 different approaches to the roll out.
I’d like to hear from Waku and Status team on the proposal, please provide insight and feedback.
I expect to settle on a roadmap in November, as part of 2025H1 Waku milestone planning.