Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
matrixbot opened this issue Jan 12, 2015 · 10 comments
Open
Labels
A-Client-Server Issues affecting the CS API feature Suggestion for a significant extension which needs considerable consideration room-vNext An idea which will require a bump in room version

Comments

@matrixbot
Copy link
Member

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
Copy link
Member Author

Jira watchers: @ara4n

@matrixbot
Copy link
Member Author

matrixbot commented Jan 12, 2015

Links exported from Jira:

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

@matrixbot
Copy link
Member Author

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

@matrixbot matrixbot changed the title We need a way to hide given messages from specific room members We need a way to hide given messages from specific room members (SPEC-84) Oct 31, 2016
@matrixbot matrixbot added the feature Suggestion for a significant extension which needs considerable consideration label Nov 7, 2016
@hukaze
Copy link

hukaze commented Jan 23, 2018

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
Copy link

hukaze commented Jan 23, 2018

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

@turt2live turt2live added room-vNext An idea which will require a bump in room version A-Client-Server Issues affecting the CS API labels Feb 7, 2019
@Biep
Copy link

Biep commented Jul 28, 2020

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
Copy link

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
Copy link
Member

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
Copy link

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
Copy link

bkil commented Nov 4, 2021

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.

@richvdh richvdh transferred this issue from matrix-org/matrix-spec-proposals Mar 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Client-Server Issues affecting the CS API feature Suggestion for a significant extension which needs considerable consideration room-vNext An idea which will require a bump in room version
Projects
None yet
Development

No branches or pull requests

7 participants