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:
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.
--
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.
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. :(
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.
left words $dvdrw right wordsIs this also a whisper? What are the contents of the whisper? What if you have multiple $usernames?