Waku brain dump - conversation with Plebbit devs

Waku
,
1

Great conversation ongoing with the Plebbit developers. It is acting as a good brain dump to explain many of the design choices we made in Waku.

Plebbit/Waku Chat History

11 June 2025

Esteban - 06:24
In reply to fryorcraken.eth
Hi yes, I remember I got the idea of doing captchas over gossipsub from that chat

[Continued] - 06:25
I was wondering if waku supports arbitrary challenges, like we are doing, for example a captcha or a password or invite code, etc, maybe it waku would be more suited for plebbit that just using gossipsub directly.

our idea with plebbit is to basically let the community owner set some arbitrary anti spam challenge himself, he can either write the code to generate / verify the challenge himself, or use some premade ones that come with the client.

[Continued] - 06:36
from reading this Explanation series - RLN Relay

it seems like that’s not something we would need, but I could be wrong. because our idea is that the gossipsub validation function would eventually prevent DDOS of our communities. (over time good peers are discovered and bad peers are ignored)

I guess something we would need would be a more tested version of gossipsub in the context of non-blockchain validation functions, like using a password or something like that.

Václav - 16:09
This is not something Waku supports out of the box. We had an idea in the past to add custom dynamic validators for messages - which would be probably what you need, but it has not been a priority yet.

Second part of this is that waku is general network - we do not know or care what payload is. All the nodes must relay all the valid messages - we only have a few validations - WakuMessage data structure, msg size and RLN. What you are talking about feels more like an application level validation to me - because I am not sure other than a particular community bodes will be able to validate against a password - how would a random Waku node know the password from a particular community?

So there are 2 levels - network/routing level validation and application level validation

And both are very important - the network level prevents anyone from spamming the network hence makes the network scalable and large network leads to more privacy and censorship-resistance. Application level validation allows particular instances to ignore messages (on app level) they do not care about and process messages that they deem valid (while still contributing to the wider network by relaying all the other messages from all the other apps running on top the network)

12 June 2025

Esteban - 04:08
In reply to Václav
I asked chatgpt questions about waku and from what I understand it seems that to use RLN you need to pay some kind of fee on ethereum, and also have access to a ETH RPC to validate that others have paid the fee.

it doesnt seem that practical to have each user pay a fee on ethereum? also access to an ETH RPC reduces censorship resistance a bit. is that the only way to use it?

also maybe I dont understand it properly, and it’s the application that has to pay the fee, in our case each community would be considered an application and have their own topic, and maybe that would make sense. but how would the application share this RLN membership with its users? maybe through some kind of whitelist, but why can’t the application do this for free using only gossipsub?

for example the admin of the application could sign something saying “user xyz is authenticated”, and anyone who doesn’t have this signed message gets their gossipsub message filtered out by the validation function. in theory this would prevent DDOS, and the ethereum fee would not be needed?

fryorcraken.eth - 10:21

This is not something Waku supports out of the box. We had an idea in the past to add custom dynamic validators for messages - which would be probably what you need, but it has not been a priority yet.

@vpavlin check the roadmap :slight_smile: IT’s a priority now

https://github.com/waku-org/pm/blob/2025H2/draft-roadmap/integrate_rln_with_waku_api.md#extract-rln-as-a-plug-in-library-from-nwaku

In short, we will enable developer to pass their own validation methods for spam.

[Continued] - 10:29

it doesnt seem that practical to have each user pay a fee on ethereum?

Early version of RLN indeed requires a refundable deposit to insert a membership on the contract.
Do note that We intend to migrate this to Status L2 which is a gasless L2 (no gas) and looking at other “captcha” to enable membership registration. See The Cost of RLN Memberships: Diversifying the Entrypoints

We are privacy focused, hence why we went in a smart contract direction, instead of phone number or email collection like traditional systems did.

also access to an ETH RPC reduces censorship resistance a bit. is that the only way to use it?

users indeed need access to an Eth RPC. However, we are keeping a close eye to Nimbus development, who are working on light client and portal network development for Eth execution clients.

but how would the application share this RLN membership with its users? maybe through some kind of whitelist, but why can’t the application do this for free using only gossipsub?

An application could indeed push the user’s RLN credentials in the smart contract themselves. The contract is a membership registry. IT does not really matter who inserts the membership.

for example the admin of the application could sign something saying “user xyz is authenticated”, and anyone who doesn’t have this signed message gets their gossipsub message filtered out by the validation function. in theory this would prevent DDOS, and the ethereum fee would not be needed?

Yes but here, you would not have privacy at the routing layer as all nodes would need to be able to say that “this message is from user xyz, who is authenticated”.
Without privacy, you loose censorship-resistance properties.

Am I guessing right that you have a different pubsub topic per community/

Esteban - 10:41
In reply to fryorcraken.eth
you could encrypt the entire message, except the signature of the sender, and the authorisation from the app owner. it could be decryptable only by another user, or by the application admin. so all you have to deanonymise are heuristics like time.

for example in plebbit we do have some privacy, as it works as a message exchange:

  1. user broadcasts a message encrypted with the community owner’s public key
  2. community owner responds with either “challenge verification succeeded”, “challenge verification failed” or “challenge”
  3. if a gossipsub peer relays too many messages that end up with a “challenge verification failed” reply, presumably their gossipsub reputation would lower until they are banned, preventing DDOS. though we are not sure if this would work in practice since I don’t think this type of validation function that happens via 2 messages has been done before

fryorcraken.eth - 10:43
yes but the signature of the sender still reveals information about the sender. This is not something we are happy to compromise in Waku.

But having said that, we do intend to make message validation as a plugin, so that should help.

Esteban - 10:44
In reply to fryorcraken.eth
yes, each community has an owner/creator, and they run a pubsub topic where they have to reply to each message with “challenge verification succeeded” or “challenge verification failed”, and these replies would presumably work to build peers reputation and prevent DDOS.

[Continued] - 10:48
In reply to fryorcraken.eth
not necessarily, the user can use 2 public keys, one for publishing encrypted pubsub messages, and one for his application username. so people watching the pubsub messages only see the pubsub public key, never the application username. this is how we do it in plebbit.

in our case the community owner decrypts all messages, so the community owner can probably link via heuristics the pubsub public key to the application public key, but a random peer cant.

it’s not fully private but it’s a little bit private

fryorcraken.eth - 10:50
On Waku and Status side, we also considered having one pubsub topic per Status Communities, we went against it for a few reasons:

  • With a pubsub topic per community there is a risk that nodes are forced to block a given community, which can be done by simply blocking the pubsub topic.
  • One can grab the IP of everyone participating in this community, by running a node on this pubsub topic and noting the IP of peers that connects to it
  • there may be scalability issues in terms of peer discovery, once there are many communities, and hence pubsub topics, one may end up with a needle in haystack problem to find another node for a given pubsub topic. Unless a community deploy their own bootstrap nodes. and in this case, censorship of the community can happening by blocking ips of the bootstrap nodes.

[Continued] - 10:52
Just to be clear, I am just explaining the design choices we made on Waku side, they may not be relevant to Plebbit as I am not yet fully familiar with your architecture.

Esteban - 10:55
In reply to fryorcraken.eth
yes I appreciate the explanations a lot, I am actually not 100% sure that the plebbit pubsub design works, it has never been tested against attacks, so that’s why I’m wondering why you guys made certain decisions instead of using a design more similar to ours. maybe there’s a fundamental flaw in our design and we simply dont know it.

[Continued] - 10:58
In reply to fryorcraken.eth
wouldnt the application, in our case the community, not block peers they want, and do block peers they dont want, so in our case, the community will always be reachable by peers that the community admin wants?

[Continued] - 11:01
In reply to fryorcraken.eth
yes that is an issue, but isnt the issue the same on waku? I assume all peers dont relay all messages, they relay subset of messages they use, so if one spies on relayed messages, couldnt they figure out what IPs are part of which subsets of the gossip topic?

fryorcraken.eth - 11:01
So basically, when looking at discv5, assuming you have one set of discv5 bootstrap nodes and you need to look for node that have a 1 property out of N. Eg, 1 specific pubsub topic, out of N pubsub topics used in the network.

If N = 100, and assuming regular distribution of the property across the nodes. Aka you have 10,000 nodes and each pubsub topic is served by 100 nodes, then it would take in average 14 discv5 round trip, which is way too much from UX pov.

Let me find the article.

So which means that if you have a lot of big communities with a lot of nodes for them, a new community may have difficulty to bootstrap as it may be difficult to find nodes of this community in the discv5 partition.

wouldnt the application, in our case the community, not block peers they want, and do block peers they dont want, so in our case, the community will always be reachable by peers that the community admin wants?

Well yes libp2p-gossipsub already does that, if oyu connect to a peer that you dont have pubsub topics in common with, then you disconnect, the issue is finding a peer in the discv5 partition (assuming discv5 is used).

If you you IPFS DHT for discovery, you may be able to solve this issue, but we haven’t looked at that (yet)

[Continued] - 11:02
here Waku v2 Ambient Peer Discovery | Vac Research

[Continued] - 11:09
In reply to Esteban
The difference in Waku is that we separate routing (pubsub topics) and application domains.

In Waku, users set content topic on messages for filtering purposes. And we divide the network in a number of shards, (aka gossipsub network aka pubsub topic).

So let’s we split the network in 10 shards aka pubsub topic.

When a new community come in, they setup a new content topic.

With autosharding, we use an algo that derive a shard number for this content topic, so that the community gets assigned a given shard.

Now, the traffic within this shard is shared between communities, in a pseudo-random manner.

So let’s says in shard 5, we have a community about kittens, dogs and guinea pigs.

Now, someone creates a community for birds that end up in shard 5.

Birds are forbidden, so some powerful actor want to ban all birds talks. In this case, they may try to block the whole shard 5.
This is now difficult:

  • the existing users of kittens, dogs and guinea pigs are supporting shard 5, so even if birds are in minority users, they get the support of a wider network
  • we use one discv5 partition for all shards. so the powerful actor may block discv5 boostrap nodes, but all communities in Waku, on any shard, is incentivised to run alternative boostrap nodes to ensure their community work

Esteban - 11:19
In reply to fryorcraken.eth
how can a powerful actor ban/disrupt a pubsub topic in gossipsub?

all I can think of is they could try to disrupt the DHT or discv5 protocol, but for example if you look at bittorrent, I dont think that happens a lot, even if someone were to invest a lot to disrupt the bittorrent DHT, there’s trackers, there’s peer exchange, there’s magnet links with peers included, etc.

I actually never looked into how discv5 works (but I will now), I only looked at how IPFS does peer discovery, and the IPFS DHT was using too much bandwidth and killing our users routers, so we switched to using trackers like bittorrent for peer discovery, with the plan on having fallback methods like a less bloated DHT, peer exchange and peers in name records later.

Nico - 14:07
Maliciously behaving peers could spam or flood a pubsub topic.

E.g. one or many peers could send thousands of pubsub messages which could results into a DDoS attack.

So Gossipsub v1.1 has a better protocol attack resistance and it will stop listening to peers e.g. which are sending too many of the same messages in a certain time.

E.g. when a peers score drops below a certain threshold it will be banned automatically for some time.

Especially when developing these protocol these threshold are immediately coming to effect and you must set them high enough otherwise you might not receive any messages after a short amount of time.

[Continued] - 14:12
This one seems new to me :

[Continued] - 14:17
Anyhow how old these specs are, it’s supported both by libp2p since around 1 year now.

Václav - 14:38
In reply to fryorcraken.eth
Damn, I cannot keep up with the roadmap updates:D

[Continued] - 14:43
In reply to Esteban
Part of what @fryorcraken was mentioning is the number of peers relaying on a gossip sub topic - lower number of peers is easier to disrupt (block, censor) by a powerful actor - so if it is a topic per community and the community is only 100 peers, and they do not use tor or mixnet to connect, they are easy to target.

Compared to Waku where even small community might be relying on thousands of peers supporting the gossipsub topic, it would be significantly harder to block most/all of them only to target 100 that are actually part of the community the actor is trying to block

[Continued] - 14:46
In reply to Esteban
Using 2 keys does not really matter - you may not be able to pin a user’s username, but you would still be able to track all the interactions with the network - analysing metadata is a powerful tool for tracking and censoring users :slight_smile:

[Continued] - 14:49
There is a good talk by Hoprnet about it: https://youtu.be/VmR_J0qNJXQ?si=cxjeGgjvEQi0sF5D

fryorcraken.eth - 14:49
Libp2p scoring implies that you can “validate” a message. The technique of “admin signs that user Alice can send message”, is a fine way to do so. But it’s not as private and censorship-resistant as we want for Waku.

In terms of disrupting a gossipsub pubsub, it’s a question of numbers. a new community is likely to start with small numbers and be vulnerable at this point in time. What we are also saying, is that this can be a problem at the discovery layer, especially when using discv5. IPFS DHT should fix that but we haven’t looked into it enough yet.

BitTorrent does not have this problem because they use a DHT where for a given file hash, you get a list of peers and then can connect to those.
This works for file transfer, because peers will want to remain online long enough to download/seed.

This may not be application to a forum network, where a peer could pop-in with they browser, read latest post and close it.

The Time-to-Live of peers is a an issue in forum and chat applications, which does not exist in BitTorrent or blockchain p2p networks.

[Continued] - 14:50

I actually never looked into how discv5 works (but I will now), I only looked at how IPFS does peer discovery, and the IPFS DHT was using too much bandwidth and killing our users routers, so we switched to using trackers like bittorrent for peer discovery, with the plan on having fallback methods like a less bloated DHT, peer exchange and peers in name records later.

I haven’t thought enough to say if such a solution would work for Waku. Keen to read any spec/doc/rfc you may have.

[Continued] - 14:51
Also, yes, RLN uses gossipsub peer scoring, aka"accept" message if there’s a valid proof attached to it, reject otherwise.

[Continued] - 14:53
in terms of the privacy of having message signature visible at network level. The intent with Waku is strong anonymity and privacy, as part of teh Logos stack, created to build alternate network/cyber spaces.

Hence why we push so hard on this, at the cost of UX etc.
For example:

  • zk proof also give you un-linkability between 2 messages of same sender
  • we are integrating mixnet protocol directly in Waku to get messages sender anonymity

13 June 2025

Esteban - 09:00
In reply to fryorcraken.eth
right actually I didn’t think my question through, now that I think about it, even if you assume peer discovery is taken care of somehow, it’s obvious that if there are too many malicious peers, like 10000, and too few good peers, like 5, which is a realistic scenario for a small community being attacked, then it would be very difficult to find those 5 good peers and stay connected to them. so the fact that waku is a global network makes it resistant to this attack. and you also gain the perfect privacy aspect that you can’t have with just encrypting message content.

so it would actually be more censorship resistant for plebbit to use a system like this, but I think one of the main blocker is that it requires to make a transaction (L1 or L2 are both difficult to onboard) for the membership, and it also requires access to an RPC that wont lie. Is it possible for the application to pay for its users? or does each user of the application need to make a transaction?

I think it would be realistic for the creator of the community to have to make a transaction, they already do to register a name like .eth, but I dont think it’s realistic for users of the community to make a transaction at the moment. most people we try to onboard to plebbit are just message boards users that don’t yet own crypto.

[Continued] - 09:15
In reply to fryorcraken.eth
we dont have documentation for it, but kubo and libp2p-js support “http routing”, also often called “delegated routing”, though the POST spec is not yet finished, but we are just using the unspecified API from kubo at the moment.

this is their GET specs Delegated Routing V1 HTTP API and this is their draft for POST IPIP-378: Delegated Routing HTTP POST API by masih · Pull Request #378 · ipfs/specs · GitHub

our plan is to use their specifications, but instead of “delegating” to find peers in the DHT, maybe we just do like bittorrent, we just store the peers in some centralised server, and if like bittorrent we have enough centralised servers, and a fallback to other slower peer discovery, like DHT and peer exchange, then it’s censorship resistant enough.

since waku is a single network, then maybe that’s not needed. but if finding subset peers is too slow, maybe using bittorrent like trackers, which are basically instant, with a fallback to discv5 would be useful. our logic is that bittorrent has been very censorship resistant, and they use trackers, so why wouldnt it work for us also?

Esteban - 11:43
In reply to fryorcraken.eth
I think on desktop people could leave the application open in the background for several hours a day (e.g. discord, telegram, etc), so they would be long time peers. if 10% of the traffic is desktop, and 10% of the desktop traffic use the desktop app, that could mean 1% of all users would be long term peers? wouldnt that help?

also the other 99% of users would be on web or mobile, so they would probably be light nodes, only participating in short burst, but they might check the app a few times a day, every day, wouldnt they still over time gather a list of good peers and be somewhat protected from too many malicious peers attacks?

fryorcraken.eth - 11:48

so it would actually be more censorship resistant for plebbit to use a system like this, but I think one of the main blocker is that it requires to make a transaction (L1 or L2 are both difficult to onboard) for the membership, and it also requires access to an RPC that wont lie. Is it possible for the application to pay for its users? or does each user of the application need to make a transaction?

Absolutely fair points.

Nimbus has developed a light-client, where the RPC can provide a “proof” that can be verified that it does not lie. This is the first step towards solving this problem.

Yes, the community admin could absolutely insert the membership themselves. We even have defined a protocol to do this in a private manner. rfc-index/vac/raw/rln-stealth-commitments.md at main · vacp2p/rfc-index · GitHub
But this is not implemented. We are finishing an upgrade of RLN to move the Merkle tree onchain so it’s lighter for clients, and introduced the deposit. We need to dogfood that and then we want to iterate on this “deposit” mechanism and anything else that impacts UX.

Ideally, we can reach a point where using a gasless L2 + some Rarimo-style PoH you can make it transparent to the user. No promises tho.

[Continued] - 11:53

since waku is a single network, then maybe that’s not needed. but if finding subset peers is too slow, maybe using bittorrent like trackers, which are basically instant, with a fallback to discv5 would be useful. our logic is that bittorrent has been very censorship resistant, and they use trackers, so why wouldnt it work for us also?

So we did implement what we call “Waku Peer exchange” where every node acts as a tracker. meaning you can ask every node about new peers they may have in a req-res.
The issue is that it’s not as decentralised, same for trackers. So you could end up in a sybil attack where the tracker gives you peers it controls, and makes you think you are “in the network” but actually does not forward any traffic to you.

Which is why on desktop, we use a combination of Waku PX + discv5 (+ rendezvous) so that Waku PX enables a fast boostrap (time to connected). but discv5 ensure that you are not sybil’d.

[Continued] - 11:55
The difference is that BitTorrent’s data is inherently validated. You have a file hash and are looking at chunks for it.
if you connect to a tracker and just give you useless peers, you know to disconnect from them because you are not getting your chunks.

This does not apply to a forum or chat app, because you are not connecting to get specific data, you are conneting to get new arbitrary traffic from users.

Something like e2e reliability (SDS, Scalable Data Sync) can help if you can get at least “one good message” from the network, as it then points to previous, potentially missed, messages.

[Continued] - 11:57

I think on desktop people could leave the application open in the background for several hours a day (e.g. discord, telegram, etc), so they would be long time peers

I think we assumed the same and had some issue. I need to catch-up with my colleague about that.
I think it may be fine, it works for bittorrent after all.
But laptop may be behind a dynamic IP, and getting suspended etc.

I think the main issue we have at the moment is that discv5 does not have a concept of time, no TTL etc, and hence you may “discover” unreachable peers.
We partially solve that with Waku PX, as a node will double check peers are reachables before returning them to a PX request.

But maybe it

[Continued] - 11:57
it is not an issue

[Continued] - 11:58
we also had a CI that used to spawn a bunch of nodes and then kills them, polluting the discv5 partition, which might have been the problem in the first place

[Continued] - 11:59

also the other 99% of users would be on web or mobile, so they would probably be light nodes, only participating in short burst, but they might check the app a few times a day, every day, wouldnt they still over time gather a list of good peers and be somewhat protected from too many malicious peers attacks?

Back to SDS here, having an application level protocol that can assess if messages are being propagated and missing should help counter the fact that a mobile may not have the best sybil-resistant peer discovery mechanisms.

Esteban - 12:17
In reply to fryorcraken.eth
so would the application need to do a transaction for each new user, or would it “reserve” some space one time for all its users?
I think it would be realistic for a community creator to do a single transaction once when they create their community, to reserve some space. but if they had to do it over and over for each new user, that would probably be too difficult.
and how would the application share this membership with its users? for example in plebbit, the user usually downloads the metadata of the community (via IPNS over pubsub) before posting, so some kind of membership key could be shared like this, but how would the community owner stop a random person from using this membership key to spam? the community owner would reply to pubsub messages with “challenge verification failed”, but the rest of waku wouldnt know that these messages were bad, and it would use up all the membership

fryorcraken.eth - 12:38

so would the application need to do a transaction for each new user, or would it “reserve” some space one time for all its users?
I think it would be realistic for a community creator to do a single transaction once when they create their community, to reserve some space. but if they had to do it over and over for each new user, that would probably be too difficult.

For sure we can do some batching to insert memberships.
I don’t know if there’s a way to “pre-allocate” memberships before talking to the user, in a private manner. As you need to know the commitment of the membership secret to insert in the tree.
Another way to frame it, got that when talking with Session guys, is that RLN gives you a generalised way to handle spam protection on the network, with nice properties.
Allowing you to shift the problem of filtering spammer to a condition of entry in a smart contract, aka a membership registry.
Keeping the two domain problems well separated:

  • prevent DoS on the network
  • vs identifying genuine users.
    An alternate strategy is to mix both whether it be including captcha challenge, or some admin signature, using TEE to prove genuine device, etc.
    The issue with having any of those strategies done at the routing layer means that when you want to upgrade, you need to do it network wide.
    Whereas, by having RLN, you can add flexibility at the contract, and add new ways to enter the contract without a network upgrade.
    Nothing stops you to have the catpcha challenge being a condition of entry in the smart contract. Especially looking at rarimo, you could use your passport as a PoH to enter the smart contract. In a private manner thx to zk tech.
    Or prove you own a genuine iphone
    or you staked some Eth
    or do some Proof-of-Humanity
    or some pays the deposit for you, etc.
2 Likes
2

If the application can already communicate privately with its user to exchange the key, presumably they wouldnt need waku? do you have an example of a use case where this would work?

In plebbit, I’m not sure how we would be able to communicate those membership keys from the community owner to the user. The only way the user can communicate with the community owner is with gossipsub. The community owner can communicate to the users through IPNS over pubsub, but he wouldnt know the encryption keys of the users to encrypt the membership key.

3

In the case of plebbit, I don’t think it would work well to require every user to do a transaction on ETH L1. I think it would be too difficult to onboard enough people.

As for L2s, it seems like it would still be difficult to onboard, as the user needs to have some gas token to make the transaction, maybe there could be some way to do some challenge and get free gas tokens, but I’m not sure there’s a way to make this fully trustless and censorship resistant.

Also presumably an L2 where you can easily obtain gas tokens would have a lot of activity, and it would make it difficult to run a full node and RPC, so the entire network would be dependent on a few RPCs that can’t be run yourself.

In plebbit, we use arbitrary challenges over gossipsub to prevent spam/DDOS. One of the challenges we are working on is actually for a user to do an SMS verification on some centralized site, then it would issue the user an NFT on a cheap L2. the user wouldnt need to own crypto or use a crypto wallet, as we just derive an EVM address from its plebbit private key, which is generated when they launch the app.

Something similar to could used with waku. For example, the user can read a community’s data for free, but if they want to start publishing, they would need some waku membership, and they could request some membership from a list of centralized sites, by exchanging it for an SMS verification, or some Twitter auth, or etc. This could maybe work if the waku memberships were valued low, like 10c.

And it would allow a user that doesn’t have a funded crypto wallet, or even a crypto wallet app downloaded, to relatively quickly onboard, as the application can generate an EVM wallet for him. We will be testing this UX soon so we will see how good it is.

4

let’s say for example in the case of plebbit, each gossipsub message is validated, as the community owner must reply to each message with “challenge verification failed” or “challenge verification succeeded”.

would that help preventing some attacks in our case?

one thing that isn’t validated would be the absence of messages, for example maybe malicious peers doesn’t relay all messages, or doesn’t relay any messages at all. It seems like if the ratio of malicious peers is very high, and the user doesn’t yet have a list of peers with reputation, it would take a long time to figure out which peers are good. maybe it would help if the community owner would publish a frequent heartbeat message?

another thing that could enhance validation is using the libp2p fetch protocol to fetch the latest message, like IPNS over pubsub does (IPNS PubSub Router). If a peer replies with the latest message from the community owner, and it’s 1 minute old, then you know this peer is somewhat good.

Also if you publish your own message, and never receive a reply from the community owner, but the last message from the community owner using the fetch protocol is newer than your message, you know something is wrong, it would mean none of the peers you’re connected to have forwarded your message or its reply to you.

5

There could be a scenario where the community owner pre-generate a number of RLN credentials, pre-insert them in the smart contract and distribute secrets to new users.

However, doing so removes the anonymity properties brought with RLN. As the owner can now monitor the messages sent by a given members, as the owner has the RLN secret.

But, in a public forum scenario such as plebbit, I guess it does not matter as much?

6

I would say that it is very difficult to find a balance between:

  • frictionless
  • permission-less

While interaction with a smart contract adds friction, it does make it permission-less.

An interesting innovation we are looking at, is the gasless Status L2, also using RLN for DoS protection, and other strategy for revenue sustainability.

Meaning gas problem is removed, and focus on can be on the right technique to differentiate genuine users from spammers.

The point of membership is to differentiate spammers from genuine users, so if a user does a “sms auth” (which I would not recommend for privacy purposes), then I would make the RLN membership free (note that an RLN membership is free on our latest testnet contract, it required a refundable deposit, not a payment).

Again, an interesting point here is that you can multiple selection criteria to enter the registry. One user may go via a “subsidised” strategy where they have to use some central service (e.g sms auth) to get in. Whereas another user may choose a more private/sovereign strategy (deposit)

One of the downside here is that the community owner’s node/software has to be online for anyone to send messages in the community (as the owner marks each message as verification failed/succeeded).

if someone takes this node down, the community goes down.
A community owner now needs to ensure that their node do go down for their community to run. This is a difficult requirement, meaning now the barrier of entry for community owners is much higher.

I might be best to reduce the impact of an owner node outage on the operations of the community.

For this we are implementing SDS, Scalable Data Sync, which indeeds, contains the concept of a periodic sync message so that users who gets one sync message, can be informed of other messages they may have missed.

At the end of the day, you are describing third level preventions against sybile attack. The first level is solved at the peer discovery layer. and second at gossipsup level.

1 Like
7

but if you can already distribute secrets to new users, then you can already communicate with your users outside of waku? so why is waku needed?

for example with plebbit we would use waku for the community owner to communicate with its users. if the community owner could already communicate with its users before using waku, then it could just keep using that communication method, and never need to use waku?

I guess one scenario could be if you have some centralized service where you pay $5 with your credit card, and then they give you some waku membership onchain. and then you can use the waku membership to communicate with the community owner. so in this case the community owner would not be the one distributing the membership, as the community owner has no way to communicate with users outside of waku.

8

The plan for onboarding for plebbit is that the user would visit the website, like https://seedit.app, they would read some stuff for free, then maybe they try to comment or vote on something, and then they are presented with a “challenge”.

I guess there are 3 categories of challenges:

  1. The challenge could be a password or invite code, maybe for people who know each other. This is nice as it doesn’t require the user to have a funded crypto wallet or interact with a third party service. It’s free, instant and fully P2P.

  2. The challenge could also be something like an SMS verification or twitter auth or something similar provided by a third party service. This is less nice, but it’s similar to current apps people are familiar with. And it doesn’t need a funded crypto wallet, and the seedit app can generate an empty crypto wallet to receive the proof of auth as an NFT. It’s not fully P2P though as you need the third party service.

  3. The challenge could require a funded crypto wallet, maybe it’s to send $1 to someone, maybe it’s to hold some NFT, maybe it’s to have a minimum ETH balance, etc. This is fully P2P, but is difficult to onboard as not many people have a funded crypto wallet on hand, ready to use.

I think waku could be used with challenge of category 2 and 3, but the higher the cost, the more difficult to onboard. for example $5 would be difficult to onboard, even with the possibility of getting a refund. I guess it could be possible for a third party service to exchange an SMS verification for a 24h membership, and then after 24h, the service gets a refund. The transaction fees would be problematic though.

Based on this, maybe communities that were already planning on using challenges of category 2 and 3 could use waku, and communities that were planning on using challenges of category 1 could keep using gossipsub.

9

If there’s no gas, wouldnt it need some centralized way to prevent people from spamming infinite transactions?

Also another thing I was wondering, if the cost of a waku membership is $5, doesn’t it mean that it relies on some oracle or stablecoin to decide what $5 is? And maybe it has some onchain mechanism to change the fee, like some admin role in the smart contract?

It seems like there would be a lot of requirements and points of failures? You would need access to an RPC that won’t lie/censor. If it’s an L2, if’s difficult to run an RPC yourself, if it’s the ETH L1, then the transaction fees to register a membership are high/unpredictable. Also presumably the membership fee could be raised or lowered by the $ oracle, and/or smart contract admin if there is one.

10

Why not use RLN without a blockchain?

Owner listen on the pubsub topic for new users. New user sends authorization message. (captcha, TXs, etc…) Invalid messages results in disconnect at pubsub lvl so no spam possible.

Owner add new user to local merkle tree then keep publishing new roots on pubsub topic.

All users create RLN proofs for each messages, all other users can verify.

Seams doable. Maybe I’m missing something?

1 Like
11

disconnection at pubsub level is possible if peerID remains constant and signature verification is enabled.
what if a user keeps changing peerID and connecting with nodes and sending auth messages with new keys…no way to prevent this kind of spam right unless i am missing something.

12

disconnection at pubsub level is possible if peerID remains constant and signature verification is enabled.
what if a user keeps changing peerID and connecting with nodes and sending auth messages with new keys…no way to prevent this kind of spam right unless i am missing something.

True, I was assuming a way to limit authorization messages.

13

our idea with plebbit is that the pubsub topic would be the public key of the community owner, and the community owner would reply to each message with “challenge verification succeeded” or “challenge verification failed”.

so all peers could keep a ratio of succeeded/failed “first seen” messages relayed to them. A “first seen” message would be a peer you’re directly connected to, relaying you a message you’ve never seen before. it’s not possible to know the origin IP of a failed message, but it’s possible to know the IP of the relayer you’re directly connected to, and “first seen” messages presumably would correlate with the origin IP, so presumably it would be possible to stop a DDOS.

we’re not sure it would work in practice, I wrote some rudimentary simulations and it seems to work:

Simulation 1: spammerNode sends 90 failed messages to attackedNode. friendlyNode2 and friendlyNode3 send 10 succeeded messages to all nodes. All nodes relay all messages except for spammerNode.

By looking at statistics from all messages received, no correlation with the spammer could be found.

attackedNode received stats
---------------------------
from            request challenge       answer  verification    failed  succeeded
spammerNode     110     110             20      20              90      20
friendlyNode2   110     110             20      20              90      20
friendlyNode3   110     110             20      20              90      20
friendlyNode4   110     110             20      20              90      20
commuOwnerNode  110     110             20      20              90      20

friendlyNode2 received stats
----------------------------
from            request challenge       answer  verification    failed  succeeded
attackedNode    110     110             20      20              90      20
friendlyNode4   110     110             20      20              90      20
friendlyNode3   110     110             20      20              90      20
commuOwnerNode  110     110             20      20              90      20

friendlyNode3 received stats
----------------------------
from            request challenge       answer  verification    failed  succeeded
attackedNode    110     110             20      20              90      20
friendlyNode2   110     110             20      20              90      20
commuOwnerNode  110     110             20      20              90      20
friendlyNode4   110     110             20      20              90      20

By looking only at “first seen” messages, there is a correlation with the spammer, so presumably the spammer could be detected and blocked by their IP address.

attackedNode received stats
----------------------------
from            request challenge       answer  verification    failed  succeeded
spammerNode     90      0               0       0               90      0
friendlyNode2   7       5               9       0               0       10
friendlyNode3   10      5               10      1               0       11
friendlyNode4   1       7               1       2               0       4
commuOwnerNode  2       93              0       17              0       17

friendlyNode2 received stats
----------------------------
from            request challenge       answer  verification    failed  succeeded
attackedNode    85      3               5       0               83      7
friendlyNode4   7       5               4       1               4       7
friendlyNode3   15      3               9       1               2       14
commuOwnerNode  3       99              2       18              1       19

friendlyNode3 received stats
----------------------------
from            request challenge       answer  verification    failed  succeeded
attackedNode    86      3               3       0               82      7
friendlyNode2   15      5               10      0               4       13
commuOwnerNode  5       101             4       19              3       19

Simulation 2: spammerNode sends 900 failed messages to attackedNode. friendlyNode2 and friendlyNode3 send 100 succeeded messages to all nodes. All nodes relay all messages except for spammerNode. If a node’s “first seen” messages has more than 50 failed with a succeeded ratio lower than 0.6, the node will be blocked.

By looking only at “first seen” messages, we can see that spammerNode was blocked after 50 messages, and attackedNode was not blocked even if he did relay a large amount of failed messages.

attackedNode received stats
---------------------------
from            request challenge       answer  verification    failed  succeeded       blocked
spammerNode     50      0               0       0               50      0               true
friendlyNode2   96      10              85      11              0       108             false
friendlyNode3   92      10              93      6               0       106             false
commuOwnerNode  7       223             9       171             0       174             false
friendlyNode4   5       7               13      12              0       30              false

friendlyNode2 received stats
----------------------------
from            request challenge       answer  verification    failed  succeeded       blocked
attackedNode    74      9               23      8               45      55              false
friendlyNode3   120     11              104     9               3       142             false
commuOwnerNode  31      221             39      173             1       178             false
friendlyNode4   25      9               34      10              1       58              false

friendlyNode3 received stats
----------------------------
from            request challenge       answer  verification    failed  succeeded       blocked
attackedNode    74      8               18      7               48      43              false
friendlyNode4   33      11              24      9               2       59              false
friendlyNode2   116     8               116     9               0       146             false
commuOwnerNode  27      223             42      175             0       183             false

It would be possible for spammerNode to keep his succeeded ratio under control and not get blocked, but then it puts an upper bound on how much spam he can send. Presumably it would also be possible for attackedNode to keep his ratio under control and stop relaying messages when he is under attack, maybe only relay messages for nodes he has a long history of high succeeded ratio with.

1 Like
14

But before the community owner’s reply gets propagated, wouldn’t the original spam message get relayed in the network among many nodes? And since each node would not know who the originator of the spam message is, they would all descore the node that already forwarded them the message. Or am i missing something here?

Also looks like you are assuming each node sends messages to every other node in your simulations? That would not be the case in reality.

I am assuming based on success first seen message you would have the gossipsub score updated from the application to ensure gossipsub disconnects a peer if score goes too low.

15

Yes I was assuming some potential centralized service. As you said, you suggest a SMS challenge as a potential solution, it goes in the same vein while keeping it more permissionless.

RLN is also used to limit spamming on Status L2 (wip)

We propose DAI as the first step.

At the end of the day, we just need consensus on what the Merkle tree look like, and what are the conditions of entrance. The consenus does need to be deterministic so that everyone has the same tree.

Other consensus algorithm could work. Also, if let’s say you want to run your own network, and be the only one to insert memberships, you could drop the merkle tree anywhere (but we loose various properties).

16

yes, that’s correct, assuming the community owner replies after 1 second (he would try to reply as fast as possible), the spammer node would have 1 second to spam at lot of messages.

presumably this would not allow the spammer node to DDOS the pubsub topic or to cause other nodes to block the attacked node, because the attacked node could see that the spammer node is relaying him a lot of messages that are pending verification. He could put a temporary pause to relaying them. There would probably need to be a limit of pending verification messages relayed.

Also if the attacked node has been in the pubsub topic for many days, presumably other nodes would have him with a high ratio of succeeded first seen messages, so they wouldn’t block him quickly.

Also presumably, the attacked node could know its own ratio of succeeded first seen messages, and it could know that it’s getting lower, and who specifically connected to it is responsible for making it lower.

I am not 100% sure this is correct, but it seems logical. do you seen a problem with this design?

yes that’s also correct, but my presumption is that the attacked node would be able to descore the spammer and block it, before it itself gets descored by other honest nodes.

are there other parameters for my simulations I should use to try to prove that this is possible / not possible? I think I should write more simulations but I am not sure what other parameters should be used.

maybe I should write the simulations using the javascript gossipsub library?

or maybe in our case, we should use floodsub, and not gossipsub. in the gossipsub whitepaper, they mention that floodsub is more likely to reach all peers, but it’s very wasteful in terms of bandwidth, since even extremely popular reddit communities with millions of users would probably only have a few messages per second each, and that each community is its own pubsub topic, it would not use that much bandwidth, so maybe floodsub is a better choice.

If you have any suggestions on how to improve the simulations I will write them when I have time. I am working on them in this repo whitepaper/pubsub-simulations at master · plebbit/whitepaper · GitHub

yes, either via the gossipsub reputation system, or some other reputation system.

17

A few thoughts from my side as well:

  1. Note that if DoS protection on your routing layer depends on lots of information from the application layer (e.g. waiting for approvals from a central owner, keeping track of past behaviour, etc.) you generally create a larger attack surface. The ideal is that a routed message can be validated simply based on the information readily available to the routing layer, without requiring keeping/parsing application state. For example, even if you keep application state by keeping track of app-level behaviour of different relaying IPs in your topology, IP cycling is not that difficult and you put users of e.g. VPNs at a disadvantage that share IPs. If an attacker has ~1 second in which it can try to DoS the community owner to the point where it fails to respond to anyone else, they will.
  2. Floodsub scales really badly - in fact, bandwidth usage increases exponentially to the number of users in your topology and not to the number of actual messages being sent. GossipSub scales linearly with number of messages being published (which increases linearly with slope < 1 to number of users).
18

yes that would be ideal, but it’s only possible via cryptography, like proof of work/stake. and both of these require syncing the full ledger or starting from some trusted checkpoint.

another cryptographic way that doesn’t requiring blockchain syncing is IPNS, but only the owner can publish.

actually in plebbit, the user usually first downloads the community metadata, or even some posts that he reads, by using IPNS over pubsub. Then after he joins a different pubsub topic to publish.

We could use some of the IPNS data to fully describe the validation to publish in the pubsub, but this would be limited. for example:

  • whitelist: a list of public keys, anyone who isn’t on the list cannot publish.

  • blockchain based challenges: any address that passes some blockchain criteria can publish.

But those challenges are really limited, for example the whitelist must be public, and to ban someone from the blockchain challenge, you must either make an on chain transaction or add a large forever growing ban list to the IPNS record. also it forces all pubsub participants to have access to an RPC.

For example some challenges we anticipate people will want to use:

  • SMS/email/social media verification
  • private whitelist (private for privacy)
  • private banlist (private for size)
  • invite code / password / secret puzzle
  • blockchain, but with no RPC access requirement and bans without onchain transactions
  • karma and account age minimum

None of these could ever offer cryptographic proofs, so they fundamentally could never be used in pubsub messages with information readily available. To be able to use them, some trusted oracle/admin must confirm their validity, so there is no other choice, even if it’s a less scalable/slower/wasteful/vulnerable design.

One idea could be to use a 2 step system, first a blockchain validation, then a community owner validation. This would fix the ban issue, but not the RPC access requirement issue.

One challenge I haven’t talked about is karma and account age minimum: in plebbit, the community owner publishes posts over IPNS/IPFS, and those contain karma and account age values signed by the community owner, so a karma/age proof could be included with each pubsub messages. But this also can’t provide banlists, as signatures can’t be revoked. And it removes some privacy, you can no longer encrypt the author of the post (maybe can be fixed with ZK). Also a new user can’t use this challenge so it can never be the only challenge.

A 2 step system could also fix the karma and account age minimum banlist issue, the first step validates the karma and age immediately via community owner signature proof, the second step the community owner replies with “challenge verification failed” if the user is banned.

If we separate the challenges into more generic categories:

  • centralized http service or blockchain rpc access:

    • blockchain balance
    • SMS/email/social media verification

  • shared secret

    • private whitelist (private for privacy)
    • invite code / password / secret puzzle

  • positive history

    • karma and account age minimum

  • negative history

    • private banlist (private for size)

It could be possible to compromise and make the private whitelist public, and remove invite code / password. To invite someone, the invite code or password owner would publish a pubsub message to tell the community owner to add a new whitelist address to the IPNS data. So all the “shared secret” challenges could be merged into simply “public whitelist”.

We could also accept that if a community owner wants to use a blockchain (eg waku) or centralized http service challenge, all pubsub members must have access to the http/rpc endpoint. The community owner can opt out of this requirement by using a different challenge. The community owner could also run a second pubsub topic with different challenges without http endpoint requirements.

Making these compromises, all challenges except negative history can be used as step 1 validation (information readily available). For the “negative history” challenge, the community owner would reply with “challenge failed” as a step 2 validation if a banned user tries to post.

19

On the private whitelist, I think cryptographic accumulators can be used for this.

The accumulator is public (but reveal no info) and members can prove they are members. The down side is updating the accumulator when members join or leave.

Zero-knowledge membership proofs are also possible.

1 Like
20

I would suggest to do somewhat larger scale simulations because with gossipsub kind of architecture small scale simulations (i.e using 5-10 nodes) will not result in actual understanding of behaviour especially scoring since that is what determines a spammer in the network.

well, that might be difficult because gossipsub mesh formations are dynamic and it is hard to predict which nodes are connected as full-mesh to spamming node and further. Which is why having a realistic running simulations might give a better idea of network behaviour.

There are some readymade simulators like testground available that you should be able to use by customizing them. I am sure there might be more recent ones you can use.