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.
- 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.
- 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.
