Can Whisper support a (Public) Chat Room?

Some discussion happened recently in the #status chat. It centered around whether or not the Status/Whisper protocol can support a public chat room. Also, some questions were raised around whether it could support a DDOS attack on a public chat room. Last, some discussion was centered around whether a multi-user chat room can be feasibly implemented.

  1. Public Chat Rooms (and thoughts about multi-user chat roomss)

The main issue here was whether there can exist some support for public chat rooms that remove the possibility for spammers to infest the message stream. As we’ve seen in the past few weeks, it is currently impossible to block messages from spammers. On top of that, it’s relatively easy for spammers to generate new accounts programaticaly and spam channels, so it is likely the spam issue will continue and get worse.

There has been some discussion about this issue, and some candidate solutions have been brought up

  • Stake SNT before allowing users to message. As the popularity of a channel grows, stake should increase
  • Stake SNT for ownership of a channel, allowing them control of said channel to block users and allow users to talk as they see fit.
  • Allow nodes to identify spammers and broadcasting messages from them.

I’m not sure if these solutions are good. A user posted a critical question recently, that I think we should think about:

How do you ban spam without enabling censorship?

I’m not sure if adding these features can fully ban spam without enabling censorship. For example, SNT is currently very cheap, and it’s not unlikely that there are a few users with lots of SNT now. As the platform grows, these users may become, or may lose control of their SNT, which enables a malicious actor to control a public channel. Along with this, staking for ownership of a channel gives users direct control of said channel, which again allows malicious actors to gain control.

I’m not entirely sure if we should solve the public chat room issue. The whisper protocol is quite clear in it’s use cases that it wants to address broadcast dark messaging between two parties. It should raise the question as to whether or not public chat rooms directly fit this use case.

In the whisper poc silent operation section, a nonce-based sequence generation of bloom filter hashes is shown to dark communicate between two parties. This is certainly the most secure way to chat between users, and one can see it should be possible to have multi-user chat where each user first exchanges public keys in person while aggreeing on a start hash for the bloom filtering, then forming a channel where each user encrypts their messages, signs it, and increments a nonce while re-hashing the previous bloom filter hash for a new bloom-filter hash. Each message would effectively change the filter hash and form a multi-user POW algorithm that identifies each user to their message. An incorrectly signed message could be dropped.

While this framework can work for users in the 10s, I cannot see how this wouldn’t form a DDOS with users in the hundreds. Clearly the A in CAP would be an issue, as each message requires users to update their bloom filter addresses. For a large enough chat room with messaging rates every 10 or so seconds, I’m not sure how a user’s cellphone could not run out of battery constantly re-hashing a new bloom filter address for every message, or even finding availability to send a message. Note this is just for private chats. One can reasonably assume for public chats this is infeasible.

Public chats invariably seem to be… well public. While public chats appear to be a good “nice to have” in the whisper protocol, we should keep in mind the goal is to facilitate secret dark communication between two parties. There is naturally a trade off. In fact, the protocol states it does not seek to optimize very common requirements of communication channels like low latency and high throughput. This is good. I think as users of the platform, we should be ok with certain features being terrible, to allow for the main goals of the project to thrive. It seems as if securing public chats only enables censorship, and in the worst case, enables parties to be blocked by node owners.

  1. DDOS’ing in General

This is an example of the protocol in action. Since messages are broadcast between nodes, one can DDOS a node and effectively DDOS the node itself. It’s clear during this phase, users using the node as an entry point will be blocked from receiving messages. Here the tradeoff is seen again. The C in the CAP theorem is sacrificed for overall availability and partition tolerance. The node will drop and users must find a new entry point into the protocol. Note, DDOS is interchangable with “spam”. There is simply no way to thwart an effective DDOS into a channel, since the system is designed to soak the messages and fail when needed. It should be seen then that pubic channels are simply not safe. Even if a filtering mechanism was built into the UI itself, there is no way to filter the data sent from the node to users or other nodes without having the node filter users. See (1) for thoughts on node control of filtering.

In short, I’m just not sure public chats are possible. While they’re a nice to have, features common with public chats appear to not be feasible while maintaining the requirements of the Whisper protocol. I am not sure if we should sacrifice the goals of the protocol in an effort to support public chats.


Here is my thoughts that I put on the #Status on the app:

I don’t have the technical knowledge to know how to do anything but a couple of thoughts come to mind. If you add a mute button would it be possible to kill or permanently mute an account that gets muted too many times on a public chat or maybe that account just can not post to that public chat anymore and all the accounts posts to that public feed are removed. A kind of public censorship of the public chat. This would discourage spam because it would not live in the feed and spammers would know they are going to get removed. Also each public forum would develop its own “censorship” based on its active uses. So if you have a #WeLoveCats and someone comes on that public chat and talks about how much they hate cats then the group can decide if they want to hear it or push them out of the group. Some public chats will become echo chambers but others will remain open forums and the open forums should take off with people of open minds.

So if I understand what your saying, the Status using Whisper should be limited to private chats and those private chats should be limited to about 10 people, otherwise the system will crush a cell phone? If that is the case I still think Status meets it’s use case. There is no shortage of public forums. The only issue is those forums are typically censored. Even Telegram shut down a channel that was exchanging music files. So having an open forum that can not be censored but could also not be spammed may be incompatible. It would be cool if Status could provide that forum.

@jrab227 thanks for the insightful contribution

I agree with your worries about censorship, very valid argument, just a few technical points:

The algorithm proposed for private group chats is essentially a synchronous ratchet over whisper topics with multiple users, these kind of algorithms really suffer in non reliable network conditions (whisper, mobiles) and with limited offline storage (mailservers), an interesting read on this point is Signal >> Blog >> Forward Secrecy for Asynchronous Messages where they go through their reasoning for moving away from synchronous ratchets (although it applies to a different context, the idea is the same).

I think CAP here is a bit misused, as it only refers to distributed data stores, as whisper nodes don’t synchronize state among them, they only act as relayers (mailservers are supposed to have shared state, but there’s no consistency guarantee, different story altogether).

The node will drop and users must find a new entry point into the protocol.

A user is generally connected to multiple nodes, not just one, though of course in a ddos scenario they might be multiple node failures

That’s all, thanks for the contribution!


So about the CAP mentions, I do feel like it appears here, but you’re right, there is no consistency guarantee in the Whisper protocol. If we’re abstract enough, we can view a user’s chat history is a data store. In terms of Consistency, I believe the requirement is to have each user have the same chat history, i.e. the same messages in “correct” order (ordered by nonce, timestamp, whatever). I don’t believe Whisper can support that. I actually see consistency errors in practice when I use the app over a crappy connection. Occasionally I will send a message and see it in my logs, but a message from another user will appear before my message after I sent the message. I take it that latency and peer connections cause inconsistent message histories, since messages just don’t reach my phone in time. Of course I’ll receive my messages eventually, giving eventual consistency.

currently even for chat history, we don’t guarantee any consistency (it’s all best effort), as you probably already noticed :slight_smile:

On the topic, there are some fairly robust distributed storage over gossip protocols, such as whisper, an interesting implementation is consul/serf, they use swim underneath, Gossip Protocol | Serf | Consul | HashiCorp Developer , from hashicorp.

Very interesting. I will check out this idea of ratchets by the way. Are there other protocols that would fit with Whisper and allow for multi user chat? The ratchet idea I typed up comes from the idea in the whisper POC paper, but I notice that the POC papers are very high level, leaving implementation details open. I just don’t know of better ways to have securer messaging between more than 2 parties.

You can fit quite a few protocols over whisper (anything that fits on a connection-less protocol will do), but basically you generally have two choices (we are talking about private communication only, public chats are easy as messages are essentially unencrypted, and whisper provides already broadcasting):

  1. You agree on a shared secret among the parties
  2. You do pairwise communications (that’s easy out-of-the-box in whisper)

1 the initial setup is harder, but then once the shared secret has been shared the operations are easy and cheap
2 is much simpler setup, but much more costly as you send 1 message per member

in terms of ratcheting over encryption keys, 3 types:

  1. Hash/stepwise ratchet, similarly to what you described in whisper
  2. OTR style ratchets
  3. Signal’s double ratchet (which is a mix of the two essentially, hence the name)

it would be very interesting to get something like swim working over whisper, just for funzies