Working Topic: Chat

18 views
Skip to first unread message

dvdrw

unread,
Aug 28, 2020, 3:38:56 PM8/28/20
to rfccom...@bitwave.tv
We all know intuitively what chat is and how it works. Sadly, that intuition, more often than not, differs, and just gets people angry.
This is the topic for hammering out the details.

Chat users can either be logged-in users, or people with randomly assigned troll IDs.
Chat users can have a tag and username colour assigned to them.

Since trolls are randomly assigned, it's technically impossible to have any persistent data on them.

Users can chat either locally or globally. Their messages are marked so.
This means they can either see _only_ the messages in their chat room, or messages from _all_ rooms, respectively.

Arbitrary chat rooms are allowed.

The chat client can filter/not display _any_ message it pleases.
However, the chat server can decide to drop messages only in certain scenarios:

  • The user exceeds an interaction limit (i.e. gets rate-limited. Necessary because of technical flaw)
  • Messages sent by users that are muted inside a room are only _marked_ as muted.
In both cases, the user sending the message must be notified in some, shape, way, or form that their message isn't subject to ordinary server rules.
(Concretely, for a rate-limit, you can have a cooldown timer; or for a mute, you can have an info message show up somewhere)

Chat rooms for which exists a users whose usernames matches the room name are 'owned'. The user whose username matches is the 'owner'.

Owners of chat rooms can curate a list of usernames which are _muted_. This list is publicly accessible by all chat members.
Muted users can send messages as regular, but their messages are marked as _muted_. Clients (read: other users) can then choose to filter out these messages.

Users who have had users on their mute list are marked as having used the functionality. This mark cannot be removed.

User chat interaction is limited by default. Room owners have the option to set the sensitivity of this rate limiter, as well as disable URIs rendering as clickable links.

In my opinion, staff moderators should have at least read access to a room's configuration for both rate-limits and mute lists.
I'm also not sure what the current standards/methods for rate-limiting are, nor what the hard caps are. Perhaps Dispatch can weigh in on this one.


herb green

unread,
Aug 28, 2020, 4:48:11 PM8/28/20
to dvdrw, rfccom...@bitwave.tv
Since trolls are randomly assigned, it's technically impossible to have any persistent data on them.

Before lots of changes happened there was persistent data on trolls.  There were at least a couple trolls who had colored names, and I'm no programmer but isn't the troll ID itself persistent data? Couldn't you just tie whatever other data that you mean to be persistent to the troll ID? Seems to me the only difference between accounts and trolls is there is a database of fake emails tied to the accounts, but what do I know?




  • "The user exceeds an interaction limit (i.e. gets rate-limited. Necessary because of technical flaw)"

I'm curious what you mean by "technical flaw" cause if the cucked "insane" mode is the technical limitation of bitwave I think we have serious problems.

Oh maybe you answered it here, but I think he was completely arbitrary how he set the limits.
--
You received this message because you are subscribed to the Google Groups "RFC Committee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rfccommittee...@bitwave.tv.

dvdrw

unread,
Aug 28, 2020, 4:53:50 PM8/28/20
to herb green, rfccom...@bitwave.tv

Basically, a single server has a limit on concurrent users and reqs/sec. Adding more servers is possible, but costs $$$.

And troll IDs are randomly generated. There shouldn't be a collision (i.e. two people getting assigned the same ID any time soon),
but "shouldn't be" and "mustn't be" is the difference between a security vulnerability and an inconvenience. :(

dvdrw

unread,
Sep 3, 2020, 7:50:14 AM9/3/20
to herb green, rfccom...@bitwave.tv, janken....@gmail.com

Janken's email, quoted:

like how @'s mentions work
whispers should be $<username>
you could reuse a lot of the code from the mentions but only allow it to be seen by the user
so that way it would appear in local and global,

a colored background for mentions & whisper messages would be nice also.

$username would be a cool option as it pretty elegantly fits into the prefix-to-username paradigm. However, you could write a message like:
left words $dvdrw right words
Is this also a whisper? What are the contents of the whisper? What if you have multiple $usernames?

On 28/08/2020 22:47, herb green wrote:
Reply all
Reply to author
Forward
0 new messages