Idea name: Scalable Friction in Public Chats / Chat timeout settings
Description: Add a chat timeout setting that only allows a member of a chat to send a message at certain time intervals. Possibly implement this automatically for Public chats (eg. add a 10 second delay for every 100 members in a public chat). For private chat groups, allow certain roles to bypass the timeout.
Use case: As a user, I want to be able to set a timeout on how often a member of a chat can send a message so that the flow of conversation cannot be dominated by a single user and the conversation can remain usable as a chat grows in size.
Target user: Community organizers that want to use Signal for larger groups
Why this is important: An all-purpose chat platform needs to allow for optional and appropriate amounts of “friction” in communication. A private small group chat would be instant, but a massively public chat should have a good amount of friction to stop constant and unreadable flow of messages.
Any other comments: Think of the difference between (1) talking in your house with a group of friends, (2) talking in a conference / committee meeting, (3) shouting in a town square, (4) posting an advertisement in a local newspaper. From 1 to 4, you have an increasing amount of “friction” in communication.
It’s possible that “tribute to talk” could imitate this, but I think a timeout setting should be considered as well.
If this is implemented automatically for public chats (10 seconds for every 100 members), it could lead to natural balkanization of large channels as they become more unusable. For example, #NYC naturally splits into #NYC-manhattan and then into #NYC-manhattan-lowereastside etc etc
If so, I totally agree. I feel that every public chat on every platform should rate limit users by default (potentially with the option for admins/moderators to bypass it per user for bots, and per channel to allow intentional user-generated flooding if so desired), and ideally it would be tied to user reputation (such as account age, upvotes, etc.) on any platform that supports it. My very first Discourse post here links to my feature request for rate limiting.
I recommend rate limiting users across all public and private channels. This encourages users to craft higher quality messages, addresses some accidental and intentional spam, helps train users to react to messages as appropriate in place of replies, and encourages message editing (when this feature becomes available) instead of another message as a correction. As this would be applied consistently to users, I believe it doesn’t conflict with the second principle of Status in the link below.
Yes, exactly. But a public chat does not have moderators by design, right? So I was thinking of a way to scale this automatically in a public chat. For example, when a public chat passes 500 people, it is considered a village. When it passes 2,000 it’s a town, when it passes 5,000 etc. And each population has an appropriate level of “friction” in communication.
I think this is a bad idea actually. I’d prefer a simple integration with BrightID or something similar. As long as someone is provably human, that should be good enough to allow them to speak. I think it could be a disaster if “upvotes” ever entered into the Status ecosystem
I suggested something similar, see Visibility Stake, the client automatically detects how much messages are being sent per minute in a room and automatically sets a good Visibility Stake, or a manual user setting. Users can talk with lower or no stake, but they might not be viewed by everyone.
I think your idea goes well with the economic rate-limiting and tribute to talk, and I think is natural to have a exhaustion based on how much a user paid.
The main obstacle is the permission-less aspect of Status Network, which directly conflicts with identifying per person, so as protocol level this would be hard. At application level, on Status Chat, it would be possible to implement some sort of economic rate limiting, or a fancy proof of individuality (like brightid), the problem with that is it rises UX barriers, which could be optional to mitigate this.
I think the best approach is to go towards a economic rate limiting per room, however on-chain (L1) solutions might be not economically viable for end users due gas costs, and as well might rise issues with privacy making it require a zero knowledge proof for match with Status Principals.
I suppose Youtube super chats already show what this looks like today. The more you pay, the longer your message displays in the chat (or I suppose the more visible it is).
Similar to disappearing messages, difficulty would be in ensuring that this is being implemented by all clients.
In a public chat, who does the money go to? Message relay node operators?
At what point are people being priced out of speech? I suppose one would begin to see public chats more as a public bathroom stall or a newspaper classified section than a real “hangout” spot haha.
Was Status planning on implementing / making use of rollups anyway? It seems like everyone in Ethereum agrees on the solution but implementation is like
In this case it should be a configuration available to the users, at least in a fork of main client, as it’s useful.
I looked up on zk deposits and looks like the money should not be withdrawable. The money could go to networking nodes on a PoS to participate in creating history epochs, also history nodes could be included, or history nodes could provide an independent service for whoever is interested in history chat.
There is no way of solving this problem of chat room, users will have to use the ones they afford to participate, or try using them with lower value in hope someone else is “listening”, it’s better than having no filter at all. Notice that chats start free, and there might be moments when some chats suggest a payment and others moments don’t, it would depend on the activity in a defined period.
This also needs to be considered for history nodes, how payments influence how long they store a message before it’s deleted.
Yes, rollups are being researched by Status team, several options are being evaluated as each have it’s drawback, but for me looks like OVM is the most promising due full turing machine support.
This makes sense. Part of me just wonders if public chats will decline in popularity in general after Status becomes more popular for personal use. For example, I could imagine the #status public room moving to a very large private chat (with moderators) in the near future.
You might be interested in the RLN research taking place in waku - Sanaz has written an excellent introduction to a fully private way of rate limiting messages, based, indeed, on zero-knowledge proofs: https://vac.dev/rln-relay
