Context
RLN
Waku v2 RLN Relay is an extension of Waku v2 Relay which provides sparm protection using Rate Limiting Nullifiers (RLN) [1].
RLN Relay enforces a messaging rate to all peers of the network (as defined by a pubsub or content topic).
To send message, a peer must be registered to the RLN group. To join said RLN group, peers interact with a smart contract where they stake coins and record their public key, pk.
The peer needs to persist and securely store their secret key, sk.
The stake can be slashed if the peer spams the system by exceeding the set rate as it would expose sk thanks to a mechanism using Shamir’s Secret Sharing.
Service Credentials
Service credentials enables two actors to pay for and provide services without compromising their privacy [2]. For example, Alice is often offline and wants to consume historical messages related to a specific app; Bob runs a node that stores messages.
Alice may want to pay Bob for the convenience of accessing messages.
Alice deposits funds in a smart contract and in exchange receives tokens.
Alice then sends a proof of delegation of a service token as a payment to Bob. Bob verifies the proof and resolves the store query.
User Pays
In the current version of RLN, the peer that wants to send messages is the one that needs to stake coin and register their pk to the smart contract.
In the proposed version of service credentials, Alice deposits asset to get token and then pays Bob.
A platform considering using Waku, would need to assume the user needs to pay to either send messages on a rate limited channel or consume services from the network.
This does not fit all app business models, especially those where the sending/receiving messages is intended to be free for users with monetization done in other ways.
Note that efforts are currently in progress for RLN to remove the need of a pecunary stake, by staking social reputation instead [3].
Platform Decides
Each platform, project, app, have their own business model. In said model, it may make sense for users to pay to send or retrieve messages.
For example, if users are using the app to provide a service and are rewarded for it, then a small price to join may be acceptable, depending on the expected reward.
On an other hand, the platform may want to pay for the user to use the Waku network. This could be to foster network effect, or deliver a MVP until incentivization/monetization rules are implemented for the platform (e.g. today, Lens Protocol pays for user’s posts using a dispatcher [4]).
By separating the payer from the user in Waku, we could enable a new variety of business models.
For RLN, the naive way would simply to have the user share their pk to the platform and the platform stake for the user. To facilitate this, enhancement of the smart contract such as batch registration could be done.
For service credentials, it does not seem that trivial:
- if platform gives tokens to the user, then the user may decide to simply redeem them as a provider would do, to no benefit to the platform
- if the platform pays a provider (Bob) for a given user (Alice), this may have privacy leaking effects.
Next Steps
Waku economic protocols are currently designed with user pays mechanic in mind/as a first step, limiting the business/monetization models.
As we move forward with said protocol, I propose to keep in mind a more generalized protocol where user and payer may (or may not) be different entities. Enabling protocols to be used off the shelves by a wider variety of projects.