MSC4325: Presence privacy

[HarHarLinks]

Rendered

Co-written with @TobiasFella at Matrix Community Summit 2025.

Signed-off-by: HarHarLinks [email protected]

In line with matrix-org/matrix-spec#1700, the following disclosure applies:

I am employed at Nordeck, Matrix community member, and Member of the Matrix.org Foundation Governing Board. This proposal was written and published a community member.

[turt2live]

Implementation requirements:

• Client
• Server

[Johennes]

Should this override apply for 1. at the very top (user is in allowed_users), too?

[HarHarLinks]

This to applies also to the other comments concerning this algorithm: We probably shouldn't make this too complicated, and perhaps even more important if it can match a similar space in the spec then it should so we have neither to design nor implementers understand an entirely new system. Admittedly allowing room IDs has already removed us from that somewhat.

Originally this MSC left the logic open (for the time being) for that reason, and only introduced the 3 fairly generic "types" of list entries: MXID, MXID glob, room ID. Tobias added in the current logic to clarify that presence is opt-in. Then I thought of ignores... Now we are well on the slippery slope of exception rules. ;)

I reckon this is about the extent the API needs to fulfill its task, and the further we go the more convenience we get at the price of introducing a complicated model of rules. In this case, we are trading the maintenance of the allowed_users list and having more extensive globs, against another rule. What's better? Idk, maybe we are approaching this from the wrong side.

Let's consider the alternative of a fully UX-opinionated and more strongly server driven C2S API part. It might roughly look as follows:

{
    "default": "<allow|deny>",
    "invite": "<allow|deny>",
    // further join rules? ...
    "dms": "<allow|deny>",
    "spaces": {
        "allow": [ "!c01dc0ffee", ... ],
        "deny": [ "!earlgrey", ... ]},
    "rooms": {
        "allow": [ "!deadbeef", ... ],
        "deny": [ "!d09f00d", ... ]},
    "homeservers": {
        "allow": [ "matrix.org", ... ],
        "deny": [ "evil.inc", ... ]},
    "users": {
        "allow": [ "@bob:example.org", ... ],
        "deny": [ "@mallory:matrix.org", ... ]},
}

(We could also split these into several events m.presence_sharing_config.defaults, m.presence_sharing_config.rooms, m.presence_sharing_config.homeservers, ... to avoid resending many long lists on updating one.)

We sprinkle a bit of logic on top:
Ignored users never receive presence. The fields (as displayed here) are ordered such that options listed further down override those higher up. The result is only returned after evaluating all rules.

1. default: should be obvious that this is the fallback most likely to get overruled. if not set, deny.
2. invite (and other join rules?): applies to rooms in general. ordered from most to least public, not sure if public is redundant with default.
3. dms: being more intimate than invite rooms, they get to override them, based on the assumption that it is more likely from a privacy perspective that a more intimate room is allowed over a less intimate one. being lower priority than spaces allows users to group a number of DMs in a space e.g. "friends", "work", ... and override privacy there. this means they can also be overridden by rooms, however the preference to client UX should be to override by users instead.
4. spaces: evaluated to room membership recursively so long as the presence-sending user is a member of all rooms in the recursion chain (continuous hierarchy: Alice needs to be a member of !c01dc0ffee and !steamedmilk to see that !earlgrey is within !c01dcoffee via !steamedmilk).
   If Charlie is a member of !c01dc0ffee, allow. If Charlie is a member of a subspace or room in !c01dc0ffee, allow. If !earlgrey is a subspace of !c01dc0ffee and Charlie is in a room in !earlgrey, deny (closest parent space). If the space hierarchy is cyclical, or the spaces do not contain each other, deny (default to privacy).
5. rooms: can override specific rooms incl dms. when applied to a space, then don't evaluate that space recursively.
6. homeservers: considered only as part of a user ID, not literal servers. @charlie:matrix.org would be allowed while @heinz:evil.inc would be denied.
7. users: highest specificity wins all.

When Alice's presence state is updated, it is up to the server to calculate all users in contact with her, then filter each user in the list through above rules, and finally federate to allowed_recipients. For example this could apply to Mallory: denied by default, but allowed by sharing an invite room, but denied by sharing a DM, denied by being a member of the !earlgrey hierarchy even though it is within !c01dc0ffee, but allowed because it is !deadbeef specifically, allowed anyway because Mallory uses matrix.org, but finally denied by a user-specific rule.

While I think this order of reasoning is simpler to understand for a human, implementations and spec should reverse this process to return early (special care needs to be taken for spaces).

A slight UI problem arises around the differentiation of DMs being displayed in a space based on space membership by some clients.

• ➖ This allows a client not complete freedom in UI design or inventing new use cases.
• ➕ Avoids client side glob parsing to display the settings nicely.
• ➖ Adds server side logic that possibly needs to be re-evaluated whenever any room membership changes.
• ➕ It makes it very easy on the client implementer to display the same abstracted settings on 2 devices, because the API is now fully abstract.
• 🟰 Does not match e.g. the invite filtering MSC4155: Invite filtering #4155 logic. (🟰 because tbh at this point we are rather far from that anyway.)
• ➕ Removing globs makes the required rules much simpler, avoids pitfalls and possible unintended side effects
• ?

...honestly, sounds in favor of the opinionated approach to me.

[Johennes]

Is the negation off here? Should the server not ONLY send presence to such users?

[HarHarLinks]

Sounds to me like that was the intention. @TobiasFella?

Suggested change

	This makes it explicit that a server MUST NOT send presence to any user that the sending user does share a room with or lists in `allowed_users`.
	This makes it explicit that a server MUST NOT send presence to any user that the sending user does not share a room with or lists in `allowed_users`.

[Johennes]

Is the worst that could happen here that a user joins the room in between the EDU being sent and received? If so this seems somewhat negligible since the new user would be included (or not) in the next update anyway?

[HarHarLinks]

Iirc we were thinking of partial state, room splits, net splits, malicious homeservers, etc. However right now I can't remember any convincing argument that holds up against the security considerations section.

[Johennes]

Some example configurations might be helpful to understand the scheme below.

For instance, IIUC, a block list would use empty allowed_users (because * would short-circuit on point 1. and prevent exclusions)? An allow list, on the other hand, would use * in denied_users?

[Johennes]

Should this exclude globs as otherwise denied_users = ["*"] would make it impossible to add exceptions for rooms?

[Johennes]

Would it also be advisable for clients to let users choose their presence sharing configuration before joining a room? I guess the join itself exposes presence-like information, too, so not sure if it's really relevant or not?

[HarHarLinks]

This API design is fairly removed from representing specific UX, because there are just too many options.

my assumption is somewhere around

• homeserver implementations set reasonable defaults (could be to require the admin to set a default)
• homeserver admins can set reasonable defaults. for example my private $community homeserver might set *:$localhost on the allowlist, but a public hs like tchncs.de would not.
• homeserver admins can set overrides e.g. even when you as user allow *:evil.inc, as admin I can refuse to send presence there. whether as a user trying to set it should result in an error is unclear yet?
• clients set reasonable defaults (they already need to for the existing "send presence from this device" flag), ideally they have reasonable login UX to remind the user of the "send presence from this device" feature.
• clients could add a setup step if they offer an account onboarding of some kind.
• clients relate their UX for "presence on this device" and "whom to share presence with" - they point out to the users when they don't match, for example if the allowlist has * but client presence is off
• now, clients are free in how they want to let users configure their "presence privacy". some examples
  • default allow/deny plus a list of exceptions (this might also be UI)
  • DMs on/off
  • private rooms on/off
  • public rooms on/off
  • list of servers
  • list of users
  • list of rooms
  • list of spaces (infer child rooms clientside!)
  • room settings of a DM -> user ID
  • room settings of a room -> room ID
  • when a room currently denied gets added to a space currently allowed show an info about that, asking to update

So about your proposal: it would be feasible for a client to show a presence option in, say, the room join preview screen. From a product perspective I can imagine this not being used too much; in fact I think the defaults for DMs/private/public rooms and server lists plus perhaps the combination with ignores will be most effective, and that would already be quite a detailed setup.

[HarHarLinks]

@TobiasFella wdyt? 256 MXIDs of up to 255 bytes each means O(64k).

Suggested change

	TODO: event size limit EDU?
	Though the spec does not currently limit the size of EDUs, this proposal can lead to extremely long lists of `allowed_recipients` being sent over federation, e.g. when presence is shared with big rooms.
	We recommend to chunk the presence EDUs to chunks of 256 MXIDs per presence EDU.
	This is trivial to implement: any remaining MXIDs can be transmitted in a second EDU.

[HarHarLinks]

See also matrix-org/matrix-spec#428