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 
IT’s a priority now
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:
- user broadcasts a message encrypted with the community owner’s public key
- community owner responds with either “challenge verification succeeded”, “challenge verification failed” or “challenge”
- 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
[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.