From db40aa7ab44f8bed210a2fd47b5e7639f42370b5 Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Wed, 2 Apr 2025 15:30:01 -0600 Subject: [PATCH] MSC: Distinction between Ignore and Block --- proposals/4283-ignore-block-distinction.md | 91 ++++++++++++++++++++++ 1 file changed, 91 insertions(+) create mode 100644 proposals/4283-ignore-block-distinction.md diff --git a/proposals/4283-ignore-block-distinction.md b/proposals/4283-ignore-block-distinction.md new file mode 100644 index 000000000..cd5a5f2b5 --- /dev/null +++ b/proposals/4283-ignore-block-distinction.md @@ -0,0 +1,91 @@ +# MSC4283: Distinction between Ignore and Block + +When discussing features around user safety, terminology like *ignore*, *block*, *filter*, and *mute* +is typically used. Though the terminology is consistent, the definitions are not. + +In a similar effort to [MSC4161](https://github.com/matrix-org/matrix-spec-proposals/pull/4161), this +proposal aims to clarify the definitions used from a technical perspective. Clients can, but SHOULD +NOT, use different terminology for their users. + +## Proposal + +The following terms are to be used by developers and the Matrix Specification itself. Effort has been +made to avoid dramatic spec text changes with this proposal. + +**Ignore** means to filter the receipt of an action without giving indication to the sender that filtering +has happened. This filtering can be done server-side or client-side, though server-side is more popular +as of writing. For example, *ignoring* an invite means that the invite enters a black hole never to +be seen by the intended recipient. + +Other platforms and protocols may call *ignores* "mutes" or "filters". Avoid these terms as they +conflict with other parts of the Matrix Protocol (namely, with notifications and `/sync`). + +**Block** means to prevent the sender from completing an action. This is typically done server-side, +but with some work, can be done client-side. Reusing the invite example, the sender would get explicitly +told "you cannot send this invite" instead of it appearing successful with an *ignore*. + +Other platforms may call *blocks* "ignores", which is mildly confusing, but swapping the terminology +would involve significant edits to the specification and its implementations. + +### Example flow: Invites + +Happy path: + +1. Alice searches for Bob in the user directory. +2. Alice creates a room and invites Bob to it, having found their user ID in the directory. +3. Bob receives the invite in their client. +4. Bob accepts (or rejects) the invite eventually. + +A *block* could be imposed at steps 1 or 2 (or both): + +* At step 1, Alice gets told that Bob has blocked them and cannot be invited. It's also possible that + Bob just doesn't show up at all until Alice enters the full user ID for Bob, at which point the + client says "@bob:example.org has blocked you". +* At step 2, Alice's invite (and possibly room creation too) fails because Bob blocked them. Alice + sees this in the error message. + +An *ignore* would be imposed between steps 2 and 3: instead of failing to complete the invite, the +invite is received by Bob's server, but the path never reaches step 3. Bob's server (or client) simply +no-ops the delivery of the invite, leaving Alice to think that Bob is, well, *ignoring them*. + +### Example flow: Messages + +Once in a room together, the happy path would be: + +1. Alice sends a message. +2. Bob receives that message in their client. + +A *block* could be imposed such that Alice's client explicitly says "Bob did not receive this message", +and either Bob's client or server would further *ignore* the message. For encrypted messages, Alice +might not even be able to claim One-Time Keys (or similar) for Bob prior to sending. + +An *ignore* would take the shape of allowing Alice to claim OTKs, and possibly even deliver key material +to Bob, but Bob's client or server would prevent the message from appearing. Some clients may elect +to minimize the message rather than completely hide it to retain some conversation context. Placeholders +like "This message is hidden because you have ignored this user." are encouraged in that case. + +## Potential issues + +Other platforms and protocols may use yet more different terminology, and could be confusing to +developers trying to bridge with or transition from those places. Noted in the above proposal, it's +preferred to instead maintain the *ignore* definition that is currently in use by Matrix rather than +rework existing features and functionality. + +## Alternatives + +Significant alternatives are discussed inline in this proposal. + +## Security and safety considerations + +Whether to use blocks or ignores (or both!) may carry some security and privacy considerations. Because +blocks are known to both parties, this may expose the intended target to increased or alternative +forms of abuse. + +## Unstable prefix + +No unstable prefix is required for this proposal because it's purely definitions. + +## Dependencies + +No direct dependencies. This proposal would benefit from a [MSC4270](https://github.com/matrix-org/matrix-spec-proposals/pull/4270)-style +glossary, however.