Visibilty Stake for Public Chat Room Governance


#3

Thanks for the comments.

Good quearion to clarify. Here is Discuss, otherwise I would be posting at PR to ideas repository in GitHub.

Now why this idea is good…
I know Kleros awesome work, but this is slightly different because we have visibility fee. I don’t think we can use Kleros to moderate public chat without visibility fee, and having this visibility fee makes porting to Kleros more complex then what we can do within our own democracy. Kleros could be used as additional last appeal method after root delegates appeal, and this would be good because it could save us from an internal failures in our message curation system.

The way I designed it should fit under our current work in Topic Democracy and Voting Dapp, as it uses subtopics to have specialized delegates and lower quorums.

I am totally open to other options of moderation and as emergency measure allow users at least to ignore users they choose (easily breakable by a silly script, btw).

Visibility fee is important because I can create as many accounts I want, and use one different to send my spam each time, from a botnet.


#4

I agree that the idea is sound and well thought,

What is not clear to me, is that it seems is based on the assumption that we want the user to stake SNT, which it’s something we might want to do no doubt, but has this been discussed before and agreed on? Or your are making a case here for this?

I think clarifying this would help us move forward with the discussion and speed up the process

Sorry if this has been discussed before but I wasn’t aware of any conversation


#5

I’ve developed the idea while writing to this thread so this specific idea was never discussed before, only that we want some kind of democratic/decentralized moderation in public groups. We can explore other ideas then this, or evolve in top of what I proposed here. Feel free to contribute.


#6

My 2p would be that we’d want to have a both,

have some chats that are moderated, which will require the user to stake SNT, where we can implement something on the lines of the idea you proposed and move in that direction.

But still allow users to join/create chats without moderation, which will not require staking anything, as I would be concerned otherwise of the entry-barrier for new users would be too high.

What do you think?

It would also be good to hear someone else’s opinion on this.


#7

I like the general idea, but this aspect still concerns me a lot, since depending on the motives, the spammer might not actually care about having the messages displayed if his goal is to make Status mobile use unfeasible by consuming everyone’s data plan through flooding public channels with spam messages. Even if users never get to see the spam messages and are oblivious to the problem, the spam load might cause his/her phone to get hot/battery to get drained. This makes me think that something like this should also be implemented at the protocol level, so that nodes don’t even forward Whisper envelopes that are considered to be spam (haven’t thought about the intricacies of this yet, but I’m sure it will come up in next week’s meeting in Basel).

There have also been suggestions to detect spam overload situations in the app and suggest to the user to mute the channel temporarily, as a dumb workaround until we implement a way to deal with this at the protocol level.


#8

The case you specify about a spammer overloading the network with data is not a direct problem of Status Chat, but about whisper.
Whisper already have security features against the type of attack you mentioned, and, if this still be a problem for Status, we can protect clients from data usage by implementing the “visibility stake” check in “message nodes” and only communicating through message nodes in case of spam happening in the whisper.


#9

If you mean PoW, the problem is that we’re restricted on mobile devices, so we can’t require a high PoW. It does seem like the nodes will need to be aware of the “visibility stake” in order to have a robust solution.


#10

Not all nodes, just the “message/offline inbox nodes” - in case of massive spam in whisper network the device would be only using this nodes to communicate (not directly whisper).
Regardless of that, we can propose enhancements in Whisper to our case (low PoW), such as an exhaustion system: we calculate how much messages one person could send per second and make nodes don’t allow too much messages coming from a single source, making the need of a botnet to attack.

By the way, this attacks are not permanent, this means that the attacker needs to be constantly flooding the network, which costs lots of resources. This still bad, because opens a way to censorship temporarily the application chat by flooding whisper.

I think this is a different topic, the type of flooding I mean is not robot automated to cause DoS, but users simply manually flooding messages.
The flood attack you mean is more a DoS attack, which I still think you would need to make it DDoS to be effective against whisper (otherwise someone would already stopped ethereum mining/transactions communication), which also is a problem to any architecture.

I think we should open a new topic about the DDoS resistance of whisper to propose solutions to that low PoW case, and here focus in the governance of the room.


#11

Makes sense! I’ll move this specific discussion to another thread.


#12

We could also have a “ignore visibility stake” option, so if user want to see other messages that have no visibility stake they might be able to.


#13

Yeah, that would make sense!


#14

Now that spam is starting to be issue, any thoughts on reviving this? @cammellos @pedro ?


#15

Agree. Would also love to see experiments around Public chats as prime real estate - radical markets SNT use case


#16

I think we need some product input, there are some issues to solve, my main concern is entry barrier, if we require a user to stake SNT, it means there is a considerable entry barrier to use Status (I install the app, I know nothing about SNT, I can’t post in public chats).
We need a bit more product input before pulling the trigger in my opinion.


#17

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.


#18

I also posted this to #Status on the app. Thanks to the desktop app I can now type longer posts. That may be a bad thing for others. :wink:


#19

I agree, we should keep supporting “free” messages, but it would not be guaranteed that everyone sees that message. The viewers should be able to choose the minimum stake required to display the messages.
Nodes itself would limit the amount of messages a specific key can create + require a higher PoW for free messages.
I don’t think that most of users will be willing to participate on public chats, rather they would prefer group chats with their relatives (where one or more administrators need to include that user) and private messaging.

The problem we are trying to solve, spam and scam, is being a concern for all social apps from history, and it literally can kill those social apps if not done (as it becomes unusable due floading of spam), so I would prefer having a small (optional) entry barrier then having the public chats unusable.


#20

To reduce the entry barrier we could make that one user, lets say alice, could trust own visibility stake to other user (bob), If bob misbehaves then Alice looses the visibility stake.

Technically Alice would sign an ethereum message that allows to use its visibility stake, could be just a part of it, and should have some timestamp validity or use nonces.

The problem with timestamp is that slashing would only be available up to that timestamp, therefore only messages with more then one day (or more) of timestamp available should be considered valid - otherwise community (humans) would not be able report it (once reported timestamp can expire, so decision could be made after timestamp expires)

Nonces could be done, but are weaker, because all this happens offchain, and status nodes could organically have different versions of the latest nonce, making bob able to deliver more messages than alice allowed. However the contract could slash if proven that bob signed a different message to the same nonce.


#21

As all of this messages are off chain, there could be a possibility of user withdrawing from the visibility stake, to mitigate that, the withdraws would be not possible or require a long time span from its completion, like 7 days, and locked if someone tries to slash, and restart after judgment is finalized.

Remembering that challenging an non-misbehave message should cause the challenger to lose it’s visibility stake, and that this is a social decision taken by an SNT based Democracy, where the loosers of decision don’t get any reward, but winners get a reward, or by an external DAO (such as https://kleros.io/ ).

Status could do this internally as an sub topic of Topic Democracy, a DAO system Status is developing, which is an abstract democracy model providing delegation and voting, that could be extended in a sub topic to have different types of rules for different types of actions of controlled (by this DAO). A discuss about Topic Democracy is being created


#22

This contract could do the locking and allow slashing by a controller (arbitrer/democracy), it can be used as one per public room, or all public rooms use the same contract and value.