matrix-spec-proposals/proposals/4283-ignore-block-distinction.md

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, 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-style glossary, however.