MSC4325: Presence privacy #4325
Conversation
Signed-off-by: HarHarLinks <[email protected]>
Signed-off-by: Tobias Fella <[email protected]>
Signed-off-by: HarHarLinks <[email protected]>
Signed-off-by: HarHarLinks <[email protected]>
Signed-off-by: HarHarLinks <[email protected]>
Signed-off-by: HarHarLinks <[email protected]>
Signed-off-by: HarHarLinks <[email protected]>
Signed-off-by: HarHarLinks <[email protected]>
Signed-off-by: HarHarLinks <[email protected]>
Signed-off-by: HarHarLinks <[email protected]>
Signed-off-by: HarHarLinks <[email protected]>
turt2live
added
proposal
There was a problem hiding this comment.
Implementation requirements:
- Client
- Server
| To do this, the server follows this algorithm: | ||
| 1. Send presence to all users matching a user ID explicitly listed, or matching a glob in, `allowed_users` | ||
| 2. Send presence to all users in a room with a room ID listed in `allowed_users` in membership state `join` (here, we do *not* allow globs, since there generally are no groups of rooms sharing useful patterns in their room ID), **unless** | ||
| 1. The user is [ignored](https://spec.matrix.org/latest/client-server-api/#ignoring-users) |
There was a problem hiding this comment.
Should this override apply for 1. at the very top (user is in allowed_users), too?
| 2. The receiving user is listed in `denied_users` explicitly or by matching a glob | ||
| 3. The room's ID is listed under `denied_users` | ||
|
|
||
| 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`. |
There was a problem hiding this comment.
Is the negation off here? Should the server not ONLY send presence to such users?
| However this would introduce the minor risk of discrepancy that the receiving server sees a different member | ||
| list than the sending server. |
There was a problem hiding this comment.
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?
| - A default value (allow or deny) | ||
| - A list of MXIDs to be treated as exceptions to the default | ||
| - A list of servers to be treated as exceptions to the default | ||
| - Allowing to share presence with all users the user shares a DM with | ||
| - Per-room settings to share presence with everyone in this room |
There was a problem hiding this comment.
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?
| 1. Send presence to all users matching a user ID explicitly listed, or matching a glob in, `allowed_users` | ||
| 2. Send presence to all users in a room with a room ID listed in `allowed_users` in membership state `join` (here, we do *not* allow globs, since there generally are no groups of rooms sharing useful patterns in their room ID), **unless** | ||
| 1. The user is [ignored](https://spec.matrix.org/latest/client-server-api/#ignoring-users) | ||
| 2. The receiving user is listed in `denied_users` explicitly or by matching a glob |
There was a problem hiding this comment.
Should this exclude globs as otherwise denied_users = ["*"] would make it impossible to add exceptions for rooms?
| some of these rooms are listed under `denied_users`, the user still receives presence, as long as they share at | ||
| least one room which is not listed in `denied_users`. If *all* shared rooms are listed under `denied_users`, the user does not receive presence. | ||
|
|
||
| Clients SHOULD update the list of room IDs in the exception list when following room upgrades. |
There was a problem hiding this comment.
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?
Signed-off-by: HarHarLinks <[email protected]>
| A possible solution would be for servers to federate presence to servers with many recipients less frequently or based | ||
| on additional heuristics (e.g. prioritise DMs, invite-only rooms, etc). | ||
|
|
||
| TODO: event size limit EDU? |
There was a problem hiding this comment.
@TobiasFella wdyt? 256 MXIDs of up to 255 bytes each means O(64k).
| 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. |
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.