RLN Design Patterns - Practical Development and UX Best Practices

[fryorcraken]

All or part of this issue is likely to become its own milestone and encompass the work tracked with #71 and #87

Introduction

The usage of RLN for the Waku Network introduces a number of UX and Dev Ex challenges.
Some of the challenges are fundamental in nature (waku-org/research#45), impacting anyone building in a given context. While other are circumstantial (#71), based on the specific needs of a given application.

This issue attempt to identify a roadmap for the latter.

Process

1. Identify a use case, clarify the user stories and requirements,
2. Understand user and messages flows and potential issues,
3. Design one or several solution to fulfil criteria, highlight pros and cons of each solution,
4. Implement PoC that uses such solution, confirm assumptions,
5. Identify assets needed for smooth dev ex (SDKs, etc)
6. Produce assets
7. Document usage

For example, in the case of Status Communities (just an example, this are not the actual agreed requirements).

(1) Use case and user stories

Status Communities:

• Owner acts as admin and moderator of a community
• Owner accepts new members via joining request
• Owner wants to pay for member's RLN membership to minimize onboarding friction
• Owner can ban member, and if paid for it, remove member's membership from RLN

(2) user and message flows

sequenceDiagram
	Member->>Owner: request to join
	Owner-->>Member: accept request

Loading

• How can member contact community owner if they do not have a RLN membership yet?
• How can owner add member to RLN contract?
• How can owner remove member from RLN contract upon ban?
• How can interactions with smart contract remain cheap?
• What privacy guarantees be provided to member? owner?

(3) Solutions

(a) Deploy a Waku node that attach rln proof for incoming light push messages
This node validate that messages are valid community requests before attaching proof
This node runs own traditional DDOS protection (IP rate limit) to not burn through rate limits

cons:

• who run such node? would that expose owner?
  considerations:
• if node is censored, member can always pay for own RLN membership

(b) Modify RLN smart contract so that Ethereum address that adds a membership can also remove membership without knowing secret.

cons:

• compromising Eth key means possible RLN membership removal

etc.

(4) Select one or several solution and build a PoC
(5) Learn from PoC, identify SDKs or protocol changes needed to provide turnkey solution. E.g. enable validation plug-in so that such node can easily validate request messages.
(6) Build said SDK/protocols
(7) Document, release

Use Cases

A. User Pays for Membership - No Infra model

Most straightforward model where the user pays for their own membership. Developer only write code and ship it, no or minimal hosting from developer (e.g maybe a webpage hosted).
Similar to how one would use Ethereum (pay own gas).

In this model, we do need to review common wallet practices and whether any catering special catering is needed.

• RLN in resource-restricted clients research#45 needs to be sorted
• Review wallet models
  • MetaMask extension
  • Status Mobile and Desktop dApp browser
  • Rainbow SDK usage
  • Wallet Connect usage
  • etc

B. Developers/project pay for Membership - Project Sponsored Model

In this model, the project or developer or ecosystem is funding the RLN membership acquisition.
This could be a model similar to:

• Warpcast: warpcast pays for on-chain (Polygon) actions
• Lens: Tokenomics pay for on-chain (Polygon) actions (need to re-investigate this).

To consider:

• Project may have affinity for a specific L2, do we want to recommend node operator to support this L2 or redirect to a specific L2?
• How does user give their RLN credential to the developers? centralized service? What are the privacy constraints. What can be done to mitigate (usage of push tor, privacy conscious users pay for their own membership, etc).
• How does a user prove their a dApp user? is the model proving ownership of a specific token/NFT or zknote (railgun), how does the project do not end giving RLN memberships to farmers?
• Is staking enabling? is project sponsoring staking or staking+fees?
• Is there a decentralized, smart contract way of doing so? Users pays fees but staking automatically comes out from a project smart contract.
• Is refund/removal needed? If user is not a user anymore (no more zk notes) then should app be able to remove user?

C. Specific Actors pay for Membership - User Sponsor User model

Basically Status Community model. #71

D. User Shares RLN Membership Across Devices or Application

Assuming user has mobile wallet, used wallet to buy RLN membership.
User visit webapp using Waku on Desktop, user wants to use existing RLN membership in webapp.

• How does user sends RLN credentials to webapp?
• What are the security implications? e.g., malicious webapp?

Similar scenarios exists:

• RLN bought in one webapp, to be used in a different webapp/fqdn
• Wallet is desktop application instead of mobile, Waku app is different desktop app or mobile app, etc.

E. User invites user - user pays for other user

Alice is already onboarded on Waku dApp, she wants Bob to join in.
Alice pays for Bob's RLN credential so that Bob does not need crypto to onboard on the dApp.

• Could some auth be present directly in the invite URL?
• Bob needs to generate RLN credentials and provide them to Alice
  • Alice scans QR code on Bob's phone
  • Bob send encoded data to Alice e.g. waku-rln://
  • Alice can then add Bob's credentails to smart contract (Alice pays for Bob)
  • If Bob monitor smarts contract, he can learn his membership id (only one way info exchange needed)

sequenceDiagram
Alice->>Bob: (IRL): "hey, join this cool dApp"
Bob->>Bob: Install/open dApp
Bob->>Bob: Selects "other user onboards you" option
Bob->>Bob: dApp generated RLN credentials
Bob->>Alice: waku-rln://key:3d9e...930c (via QR code, NFC touch or message using centralized service)
Alice->>Blockchain: insert key 3d9e...930c
Blockchain->>Bob: membership index is 42
Bob->>Alice: (in dApp) "Thank you!"

Loading

[fryorcraken]

An idea regarding sponsorship of RLN membership. we could have a special content topic or pubsub topic where RLN is not applied but instead another rate limit rules are applied.

Message would contain:

• Blockchain address + signature
• blockchain identifier (e.g. chain id)
• RLN ID
• app name or equivalent (first bytes of hash of app names), could be part of content topic

All nodes

• verify that address and signature match
• verify that address has blockchain activity on said chain
• put some sanity rules on app name or equivalent (size check)
• limit number of messages for a given address per day

Sponsoring node (run by developers or special user):

• do same check than other nodes
• confirm user is legit (user has specific on chain activity such as ERC20, NFT, zk note, etc) or maybe whitelisted

Cons:

• blockchain address is linked to RLN ID: this ALMOST is the same than interacting with smart contract. difference is that user has to reveal specific activity. This could be mitigated because user could already be known to use app (e.g sent fund to railgun)
• blockchain address is linked to app: similar issue than above. using hash of app name is a way to introduce k-anonymity.

[lucille-bellepleure]

Labs is working on E <3

[fryorcraken]

For C., I wonder what would be the security implication of a community owner pre-registering 100 memberships (generated 100 keys locally) and then distribute secrets to community members.
The owner will not use the membership to send messages, as the whole point is to enable their members to send messages.

What information can the owner learn from knowing the secret? @rymnc, thoughts?

[rymnc]

If the owner device is compromised, then all participants will get slashed.
I would greatly advice using a stealth commitment scheme that allows a server to generate commitments that only one user may derive private keys for

poc: https://github.com/rymnc/erc-5564-bn254

[fryorcraken]

Need to add another pattern in terms of credentials sharing. The simplest use cases/way to frame it would be:

1. How should a user handle several apps? Use the same credentials across apps or get new credentials for each app.
2. How should a user handle several devices? Ditto.

Some concrete use case:

• User gets credentials via mobile phone wallet, can he re-use same credentials in desktop browser web app?
• User gets credentials via one web app, can he use them in another web app? If so, how? What are the security implications? (browser storage is not shared across domains. trusting JS code, using extension to generate proof).

[kaichaosun]

Here are the scenarios I may embed in a demo messaging app and related to RLN,

(Related to C) For group chat, community owner pays for the RLN

• community owner share a link to join the community
• user access the link in a web page, and connect with Metamask wallet or others.
• user sign a message to prove ownership of the address, pre-defined scripts from community owners check the address whether it's allowed to join, such as the address holds a specific NFT.
• if check passed, the address get its membership registered and membership fee payed by community owners.
• the webpage redirects to the app catalog page which could be endorsed by token curated list.
• user select a specific app and go to app's web page with the community link as part of the URI. If it's mobile or desktop, download link or QR code is showed, once user confirm app downloaded, the community link or QR code is shown for joining.
• starts chatting.

Notes:

• pre-defined scripts could be templatable by community devs and could be incentivized in some way.
• user could create a new credential for RLN without linking to the main ethereum address, even transfer the membership somehow. But it will add complexity in UX and should be performed carefully.
• community owner deposit the funds into a contract which is estimated by potencial number of community users.

(Related to A, E) For 1 to 1 chat, either self pay for the RLN, or pay by another actor and shared with inviting link

• Alice wants to talk to Bob
• Alice knows Bob's ID, she creates a 1to1 chat by add Bob's ID using her favorite waku compatible messaging app
• App ask Alice to acquire the membership of RLN before creating a 1to1 chat, optionally she can buy RLN for Bob if Bob don't have a membership yet.
• Alice notify Bob somehow to check her messages with a waku compatible app with a message link.
• Bob use the link to access the app and login with the ID embed in the link.
• starts receiving and responding.

Note:

• ID could be an ethereum address or ENS name or another globally registered handle
• Alice don't have to buy RLN for Bob, but her messages may be only read and not respond by Bob if Bob decides not pay for RLN by himself.
• Bob could furthur transfer the membership.

Questions,

What's the price of the RLN membership?

Currently, the RLN membership is network level and not community level. Fine-grained control by differentiate multiple levels of RLN membership could be helpful by split network loads, which could result in lower price of such membership?

What if I want to provide free tier for 1to1 and group chat, how to make it acceptable within The Waku Network/community? With an upgrade option available to use RLN for extra features like spam protection, use relay/store service in a high priority and longer persistence.

Different roles should have different settings regarding messaging rate, will RLN be a good fit for this kind of requirements?

[fryorcraken]

(Related to C) For group chat, community owner pays for the RLN

Moving the convo to #71 (comment) to not bloat this issue.

[fryorcraken]

for B. We could provide software for developers to deploy a waku node with light push that attaches memberships to messages in behalf of users. Then the user can move from a free tier and use the same node to acquire a membership via stealth commitment.

[fryorcraken]

For E. and generally, can a referral system be in place with kick back for users?

[fryorcraken]

Idea for B. #148
Where instead of inserting memberships for users, the project attach proofs for users. Particularly relevant when using Waku to ask for wallet signature (tx, auth).