Application Defined Message Validation

[fryorcraken]

Problem

In terms of spam protection, 17/WAKU-RLN-RELAY implements a stake-based rate limit protocol.

However, asset staking and rate limiting are not desired by some applications. Staking increases on boarding friction and rate limiting may deteriorate usability.

This issue tracks alternative ways to reduce undesirable message traffic when a validity check can be defined by the application.

Reducing undesirable traffic would enable Waku to scale by:

• Reducing DB size for store nodes
• Reducing bandwidth usage for relay and filter

Community based applications

A community based application may be defined by the following properties:

• Community owners create a community and can moderate their members
• Members can join a community and can be removed from a community by the community owners

Other assumptions

• Content moderation is kept out of scope (to keep scope reasonable)
• The exact user access policy (UAP) depends on the application.
• Applications are expected to use different content topics per community and functionality (e.g. joining community vs chat in community)

Examples

Examples of community based applications are:

• Status Communities
• Swarm.City

User Access Policy

Assuming a UAP where a user needs to request access to a community before they can send messages in this community.
With such policy, the application must define a logic that enables the identification of messages sent by community member (legit) versus message sent by non-members (spam). Let's define this logic as message validation.

A node operator that stores messages for a community application (may not limited) may be incentivized to run the message validation as per the application's UAP to reduce the consumption of resources by messages considered as invalid by the application.

Acceptance Criteria

Define:

1. How a service node should expose a plugin API to enable application specific message validation
2. How application developers should write said plugin and ask/make them available for service nodes to run them
3. How application developers should design message validation and UAP so it can easily be implemented in a plugin.

1 & 2 are needed shorter for Status Communities scalability. 3 can be done as a second phase.

Notes

Message Validation Models

Status Communities

When a user wants to join a community, they need to send a join request to the community owners.

Once the owner approve the request, they:

• include the member's identifier in a message sent to all existing members (community description message)
• give to the new member the symmetric key to be used to encrypt and decrypt messages for the community (TBC @cammellos?). This key is assumed to be non-trivial (@cammellos?)

For this model, it seems that the community owner would need to provide the key and member list in the plugin to enable service node validation.

Possibly, the owner would need to explicitly select a node that implements a Status Communities plugin and send it the data required for validation.

Do note that considerations may be needed to protect service node from "spam" Communities (ie, malicious Community Owner).

Generalized UAP

Can we define a generalized protocol that enable message validation in a community application?

For example:

• service credential for a community owner to request processing and storage of messages for their community and community their message validation at the same time (or does it fall codex's domain of paying for data to be stored?)
• generalized logic to get members for a community (on-chain or off-chain zk group maintained by owner?)

RLN + Message Validation

When the UAP requires users to request to join, this may happen on a public channel. In this instance, a rate limiting protocol would protect the channel from DDOS.
For said channels, a shorter or zero store retention policy could be used depending on the community owner's node availability requirements.

Can the protocols be extended to permit an application developer (or DAO?) to treat all application users as part of one community?

[alrevuelta]

Perhaps we can achieve this by generalizing 17/WAKU-RLN-RELAY? I mean, ultimately rln just exposes a secret when exceeding a limit of messages per second, and this secret can be used for slashing the deposit, but we can also use it for revoking access to an already whitelisted user.

So my 5 cents on:

Can we define a generalized protocol that enable message validation in a community application?

We could formulate this as a different application of our existing RLN protocol:

• Instead of whitelisting a user by forcing it to deposit some collateral, the user is whitelisted by other peers (approved by the community)
• If the user spams, instead of slashing the tokens it deposited, we remove it from the whitelist with the proof that it spammed.

Maybe I'm missing something, but we could generalize RLN to make it work with different smart contracts:

• one that requires staking and slashes it if we detect spam. afaik the one we have.
• another one that a set of trusted entities (community) whitelists users, and if we detect spam, we revoke the access with the rln proof.

[oskarth]

@fryorcraken thanks for creating this issue, looks good.

Only thing missing maybe, but a bit orthogonal, is the combination of RLN for send and then storing valuable messages + service credentials to incentivize store nodes to actually keep around these more valuable RLN messages. That combination would be quite valuable I believe.

Of course, this assumes we proceed with the protocol incentivization roadmap as planned end of last year, and re-iterated this offsite as a critical piece of work cc @staheri14 @s1fr0

Nitpick: let's not add milestones to new research issues, this requires a bit more thought before committing to them.

[s1fr0]

give to the new member the symmetric key to be used to encrypt and decrypt messages for the community

In this scenario, if you give the "community" key to the user, if you later remove him, he would still able to decrypt new messages. With ZK etc. you can prevent him from sending messages, of course, but not from decrypting them.

The dumb solution is to re-distribute a new key to all users when a member is removed, but then you lose decryption of old messages for new members. I think we need some sort of Attribute-based encryption with a revocation mechanism, but this will put too much centralization on community owners. The problem is not trivial at all.

[fryorcraken]

@oskarth re milestone, this was the only default template available when creating an issue (ah, I realized I should have use "new blank issue", lesson learned).

[fryorcraken]

In this scenario, if you give the "community" key to the user, if you later remove him, he would still able to decrypt new messages. With ZK etc. you can prevent him from sending messages, of course, but not from decrypting them.

I have seen @cammellos discussing this aspect recently somewhere. Could you please confirm, my understanding of Status Communities protocol is correct?

I believe that yes, a user (e.g. Alice) removed from a community may still read only the community messages. But access to a community is more write focus. Because Alice would not be present in the list of members (sent by community admin in community description message) then the other users would know to drop Alice's messages (at application level).

[cammellos]

I have seen @cammellos discussing this aspect recently somewhere. Could you please confirm, my understanding of Status Communities protocol is correct?

If the community is encrypted, we re-key as @s1fr0 mentioned when a user is banned/kicked, we allow though new users to catch up by seeding them as they join with the previous keys, so that they can catch up, up to a limit.

I believe that yes, a user (e.g. Alice) removed from a community may still read only the community messages.
If the community is encrypted, they will only be able to read messages that have been posted before they have been removed.

I think what you are referring to is communities without encryption, where we allow users to see it "read-only", and just check for write permissions, but those are not encrypted.

[fryorcraken]

combination of RLN for send and then storing valuable messages + service credentials to incentivize store nodes to actually keep around these more valuable RLN messages.

@oskarth should we open a different issue to dig on this topic? I am not sure I understand 100% why RLN messages are more valuable to store so keen to read a small write up on that.

---

Possibly, the owner would need to explicitly select a node that implements a Status Communities plugin and send it the data required for validation.

There is an incentivization opportunity here which is more application driven that I think is important.
This is fits with running a service node in a high performing cluster environment, with more performance DB engine such as postgres.

In the case of Status Communities (but can apply to any project really), a Community owner that bootstraps a community but does not want to run their own node (or store all messages on their laptop with Status Desktop) could pay any Waku service provider to store messages for 30 days for them.

[fryorcraken]

In the case of Status Communities (but can apply to any project really), a Community owner that bootstraps a community but does not want to run their own node (or store all messages on their laptop with Status Desktop) could pay any Waku service provider to store messages for 30 days for them.

I realized this starts to look like Codex and falls in this domain: paying for data storage and verifiability of said data being stored/available.

[fryorcraken]

Note that this does not help with 1:1 messages and private groups.