We need a way to hide given messages from specific room members (SPEC-84)

[matrixbot]

If you're trying to loadbalance messages between multiple users in the same room, you may want to make the message only visible to subsets of the room at any given time.

This is similar to ACLing off historical message visibility if you so desire.

(Imported from https://matrix.org/jira/browse/SPEC-84)

(Reported by @ara4n)

[matrixbot]

Jira watchers: @ara4n

[matrixbot]

Links exported from Jira:

relates to https://github.com/matrix-org/matrix-doc/issues/440

[matrixbot]

Another use case for this is an email gateway, where you want to put an inbox into a room - but want to let other people view that inbox, but only the messages they were cc'd on.

-- @ara4n

[hukaze]

Or in the case that you want to create a support room where users can hit the support team but that can not see the other support requests from all the other users in the room.. direct messages to the users via 'quote' and broadcast messages will be the only messages that they can see.

[hukaze]

this is NOT the same as whispering since this would be a room configuration as opposed to a user choice.

[Biep]

This meshes closely with a broader generalisation proposal that I made earlier - one that would drastically simplify by unifying a bunch of things that are now separate.

[conny3496]

This would be a great feature. Our use-case for this: A service-room where the agents and customers are present.

The customers can message within the room and agents can read those. Agents on the other hand could write internal-only-message which can be read by other agents but not customers. An agent can decide if there message is internal-only or public before sending - changing the state of one message after sending would be optional or only possible withing the usual edit-time-frame.
In this case a customer would be having power-level 0 and agents would be having e.g. 50. Usual messages could be read with power-level 0 but power-level 50 is needed to read the internal-only-messages.

[turt2live]

I think this would be highly related to whisper mechanics, as it effectively would mean limiting history to a particular individual or individuals (@mods sort of deal).

Now that we have encryption, we can probably send an encrypted m.whisper event into the room and distribute keys to those who need them. This should even work in an unencrypted room given all the key sharing shenanigans we do (though for good measure we should stick an algorithm flag onto the cleartext event so the receiver knows what to do with it). Clients would simply ignore m.whisper events they don't have keys for.

It would mean gatekeeping whispers to clients which support encryption, but with Pantalaimon being a thing and encryption quickly becoming a default in the protocol it's not unreasonable to expect encryption to work in a Matrix client.

[kevincox]

I think whispering is the right way to do this. For example in public rooms someone could join from another account and see the message. For private rooms it isn't as much of a concern but it probably doesn't hurt to make it whitelist instead of blacklist based. This also meshes really well with e2ee and sending the keys for just the relevant clients.

Side note: I wold love to have bots in e2ee rooms that don't get messages by default, but just get messages that are specifically addressed to them. This would allow inviting bots to a secure room without exposing most of the conversation to the bot operator. This would be nice to enforce with e2ee and excluding some participants from the keys.

[bkil]

I think the discussion has went another way, but I'd like to piggyback on the original question. Could we have a way so that (sub-)moderators could hide/unhide messages (spam or offensive speech) from common users until a higher PL moderator could redact them?

Having such a moderation log/audit trail would allow adding a lot more (sub-)moderators to a room with confidence. It is just too easy to misclick and/or to redact & kick-ban people without a way for admins to find out when the actions of a moderator were motivated by trolling or politics.