Reverse Ghost Users [Feature Request]

[ZizzyDizzyMC]

I would like the ability to specify via command to perform a reverse ghost on users.

It would work like: /rghost <username>
This would make it so messages you post in chat do not show up on that users account at all.

There would also be /rghost guest and /rghost anon to ghost guests and anonymous users from being able to see your chat.

This is to be completely server side - IE the frames you send are never sent back out to a ghosted party.

Some users do not like the thought of anonymous users snooping.

[Remark0]

I second this feature

[PinkMawile]

This feature would help greatly with harassment and snooping; I would love to see it.

[Xaekai]

Context on the term "ghost": It's what I called the ability to persistently ignore users I made in my channel JS before that feature was created upstream.

[Firebolt1089]

I'd like this feature. It would help protect against bots and the like.

[thexchan]

I would love to have this feature.

[calzoneman]

Thanks all for the context.

There are a few problems that would need to be worked out before something like this could be implemented.

The first is technical: CyTube currently treats chat messages as broadcast events, meaning a single message is passed down to the socket layer (in this case, socket.io) which encodes the message once and dumps the bytes to all users in the channel.

This has a couple of subproblems; first, socket.io broadcasts are more efficient than individual socket writes because the message is only encoded once and the same payload is distributed to everyone. This doesn't work for rghosting because specific sockets have to be excluded depending on who the sender is. I would have to look at whether they've implemented a way to manually distribute a pre-encoded payload to a subset of sockets. Secondly, filtering rghost messages requires more resources (linear with the number of connected sockets) because for every message it has to consider every possible recipient to ensure the recipient is not rghosted (contrast with channel mutes where the server only needs to check if the sender is muted and discard the message). There are potentially ways to optimize this for CPU efficiency at the cost of additional memory + code to manage it, but in any case the solution would require investigation and performance testing to ensure this doesn't regress for channels with 100s/1000s of clients and/or 70+ messages/sec.

The second problem is behavioral: features like this require a lot of careful thought to close loopholes that allow malicious users to easily bypass or even abuse the feature to their advantage. Especially once people find out this feature exists, it's practically an invitation to find a way to work around it in a covert way that's not easily detectable unless RFC 3514 is widely adopted. For example, rghosting anonymous users is called out as a separate command in the above request, but I think it's actually required for the feature to work at all because a lot of trolls are sufficiently observant to open a new private tab to observe when they are being muted. There are possibly other ways this feature could be abused to the malicious user's advantage, and edge cases to consider such as moderators not being rghostable.

To follow up on one point:

Some users do not like the thought of anonymous users snooping.

Some months back, a GitHub user contributed a feature to require users to log in (as a registered user or a guest) in order to join a channel (this is a channel setting and not a per-user setting, but if we're talking about individual users trying to avoid their messages being seen in a public channel, you're not really guaranteed privacy anyways -- channels with bots that log chat and make it publicly available, people taking screenshots of chat, etc.).

There is also #791 which requests the ability to whitelist users as a more robust alternative to passwording, which hasn't been implemented, but I'm happy to discuss if there are channels running into issues with authentication.