MSC: Distinction between Ignore and Block

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.