Waku and webapps - sign/auth from browser RLN creds mgmt catch 22

fryorcraken commented 3 months ago

Not a formal design but some thought on Waku in the browser and catch-22 of handing RLN credentials from a wallet while allowing webapp to send messages over Waku.

Assumptions / Facts

Starting point:

js-waku mainly uses websocket as transport
websocket in the browser is unreliable and we have scheduled work to remediate to it
The question on how to manage RLN credentials securely, especially in the browser is yet to be answered.
If Waku were to be used to enable a webapp to request transaction signature from a wallet device, then we have a chicken and egg problem in terms of getting a wallet signature to insert membership, and needing a membership to get such signature.

Delegating Proof Generation

Waku implementations currently assume that the client generates the RLN proof and attach it to messages sent over light push. However, delegating proof generation to the light push service node is possible. In this instance, the service may need some incentivization to do so. For example, it could be a node run by an application team, who generate proofs only for their users.

In such instance, the service node can acquire a given number of credentials and rotate through them. The service node would apply their own rate limit strategy, using IP or application user id to apply the rate limit/DOS protection (or cloudfare).

Infura Model

By opting to delegate proof generation from the browser to the service node, a webapp developer can remove the friction that RLN brings, avoiding handling of RLN credential managements in the browser. In this instance, a developer could either deploy their own Waku node to attach proof for their users. Or give the task to another business, a la Infura. The developer would pay said business to generate proof for their users. Falling back to a traditional (REST) API model.

There are several risks with such approach in terms of Waku desired properties: privacy & censorship-resistance. Especially, if a single provider dominate the market.

censorship-resistance: users can get (geo-)blocked from using said provider, controversial webapps can be deplatformed too.
privacy: said provider can correlate IP addresses and usage of a given app.

However, this could be more private than infura if application traffic (Waku Messages) is encrypted and content topics are used as buckets.

App-owned infra

Another model is for app developers to run their own infra. This would mitigate the censorship-resistant and privacy caveats listed above by making them closer to the current limitations of web apps:

censorship-resistance: the possibility of the app to be deplatformed is reduced, as the app dev run their own node. Users can still be deplatform, but this risk always exists for webapps.
privacy: The webapp, via web server operation, already has the ability to link IP and usage if build and deployed to do so. Also running the Waku node wouldn't aggravate this risk.

(the points above must also be reviewed properly, this is not a formal study). The main friction remains in enabling web developers, to operate their own infra.

Packaging Waku in the backend

Web devs are unlikely to want to become devops to use Waku. One potential strategy would be to pack a Waku RLN relay node in the web app backend:

sequenceDiagram
    actor FE as Front-End (Browser)
    participant BE as Back-End (Cloud)
    participant Waku as Waku Node (Cloud)
    FE->>BE: message 1
    BE->>Waku: message 1
    Waku-->>Waku: generate & attach proof
    Waku->>RLN Relay Network: message 1 w/ proof

Frameworks such as Next.JS actually enable web developers to build front end and server logic in one repository & application, and deploy them using Vercel. In such applications, the BE side usually handles caching and server-side rendering or even database access (afaik).

I do not know the limitations of such framework. It would be interesting to attempt to build a single NextJS app that

runs a waku node on the BE side
FE and BE communicate via standard transport (websocket, REST API)
embed an admin GUI for developer to manage RLN creds in the BE
Waku nodes in BE attaches proof
Standard DOS protection (IP rate limit) is applied by BE. Also only user authentication (token gating, etc) could also apply, depending on the application type.

Result

In such a model, the developer has sovereignty on their usage of Waku. They can acquire more membership from their node if their app usage increase. They can also remove any friction from the end user to own RLN credentials.

This mode is very similar to the Farcaster hub model.

However, it does not allow full FE webapps or for webapps to be mirrored on various platforms (GitHub pages, IPFS, etc). Which means no sovereignty for the user, unless they deploy it themselves.

Note: thank you @kaichaosun for the very insightful conversation.

weboko commented 3 months ago

Which means no sovereignty for the user, unless they deploy it themselves.

This is the base line: unless user owns the program that is running - there is trust involved.

For RLN running a program - in Browser it means to have implications on UX. Not running would mean to be fully dependent on the back-end (traditional client-server model). If we proceed with this then other js-waku protocols can be just substituted with nwaku implementations wrapped for nodejs.

Currently js-waku's strongest proposition, as I see, is discovery it proposes - even knowing it is still served from some server (can be banned) and connected to lightPush nodes (can be dropped) - it is still resilient as it can discover the network and connect to other nodes.

With that if we decide to go with REST model - we can as well deprecate js-waku and rework it into convenient library for REST APIs.

Packaging Waku in the backend

I cannot add anything to what was described. It would be needed to communicate that traditional protection such as authorization should be implemented. Can be a room for us to provide solution like authorization based on NTF or whatever.

fryorcraken commented 3 months ago

With that if we decide to go with REST model - we can as well deprecate js-waku and rework it into convenient library for REST APIs.

Note that the description above is one potential design for a wallet sign over waku SDK, that tries to solve the chicken and egg problem of needing to use Waku to get a transaction from the wallet, and needing a transaction from the wallet to use waku (get RLN membership).

I think once we start working on this SDK, the team will have to come up with a couple of solutions, such as this one, we can then pick one and test it out.

Moreover, this does not mean that it is the design of choice for all web app using waku for any purposes. Neither does it mean that if a webapp uses Waku wallet sign SDK and also uses waku for other features, should all msg go through the same "backend dev node".

Let's say we go for this design. The web app dev would need assign a few rln membership to their nwaku BE node. They will also want to ensure that these membership and nwaku BE node are only used for msg/tx signature for their webapp. So likely the REST API:

needs CORS protection on webapp domain
is not the nwaku REST API, but another one that does some validation check (ie, is this a signature request) before passing the message to the Waku node.

fryorcraken commented 1 month ago

Note we are actually going in this direction with RLN-proof-as-a-service. Meaning that the webapp would not need RLN credentials.

It's now a question on how the service node would be incentivized if the web app needs to send message to pay. But there is more flexibility there.

waku-org / pm