MSC4495: Selective Presence by thetayloredman · Pull Request #4495 · matrix-org/matrix-spec-proposals

thetayloredman · 2026-06-25T21:18:42Z

Implementations:

Client: none
Server: none

This proposal is written as part of a community-led effort called Presence v2. Context and prior discussion can be found in #presence-v2:zirco.dev and in the initial conversation that gave rise to this initiative.

Author: @thetayloredman @lveneris

Signed-off-by: Logan Devine logan@zirco.dev

Co-authored-by: Tyler J. Russell <tyler@kludgecs.com> Co-authored-by: Henry-Hiles <henry@henryhiles.com> Co-authored-by: timedout <git@nexy7574.co.uk> Co-authored-by: stratself <126093083+stratself@users.noreply.github.com> Co-authored-by: 31a05b9c <sys@31a05b.net> Co-authored-by: 7w1 <noreply@sl.sable.moe> Signed-off-by: Logan Devine <logan@zirco.dev>

Signed-off-by: Logan Devine <logan@zirco.dev>

turt2live · 2026-06-25T22:26:32Z

Implementation requirements:

Client (account data)

Client (state events)

Server (sending federation)

Server (receiving federation)

Server (backwards compatibility)

Server (endpoint - using)

Server (endpoint - serving)

This also fixes a rogue "populated" in the EDU updates, which conflicted with the case where there are updates but not for a particular remote. Signed-off-by: L Veneris <tyler@kludgecs.com>

HarHarLinks · 2026-06-26T11:27:05Z

+theory, it also offered a mechanism for other users to request your presence. However, Synapse historically
+[accepted all presence requests automatically][#4417], ultimately resulting in the feature's removal prior to r0.
+
+[MSC4325: Presence privacy][MSC4325] attempts to solve this problem by reintroducing a concept similar to Selective


As author of the much rougher 4325, I endorse this MSC as it appears to follow a similar approach but has a very simple model worked out that is easy to understand as MSC reader. Particularly I think that dropping wildcards is (mostly) a good idea.

Regarding whether it solves the 2 problems of server performance and all it's features actually getting used (the presence list issue), we will need to watch how implementations fare in practice.

I personally don't agree that dropping wildcards is a good idea, as it doesn't allow me to use presence the way I'd expect it to work (broadcast by default), or addressing a group of users by mxid format (eg. {"allow_servers": ["rory.gay"], "deny_users": ["@ext.*:rory.gay"]})

There are two things to note here:

No matter how much you improve the performance of presence, broadcasting public presence creates unnecessary traffic for users that are not actively interested, and can lead to situations like the one presence is in now

Doing glob parsing on arbitrary user-provided strings is a security issue, and users are not typically grouped together by sections of their localparts except for in appservices, which is a narrow use case already but you can still send presence to them easily since they will probably share a room

This rationale is given in the proposal already.

for point 2, isn't this already the case for server ACLs for example anyways? Besides, could be done by the local server, I suppose?

I personally don't agree that dropping wildcards is a good idea, as it doesn't allow me to use presence the way I'd expect it to work (broadcast by default), or addressing a group of users by mxid format (eg. {"allow_servers": ["rory.gay"], "deny_users": ["@ext.*:rory.gay"]})

This may be true, but in practice globbing by MXID (particularly allow) is a mostly unrealistic use case. Similarly I doubt that allowlisting a whole server that 1) isn't your own home 2) of nontrivial size is not an edge case. The real convincing point to me is though that this would be impossible to build usable UX for and is thus asking for trouble.

HarHarLinks · 2026-06-26T11:31:43Z

+}
+```
+
+### Room Presence Sharing Hints


I was very wary about letting another party effectively control with whom I share my presence before I realized I need to opt into the rooms first to then follow their hints. I think this opens the door for simple UX that users might expect as an aspect of their choice, especially coming from other platforms, with a client-local setting to "allow all" rooms. In general my philosophy is that most users will likely want to set simple global toggles like "none", "all", "contacts", etc.

For this whole hints feature it will be important to see how well it gets adopted an actually used, based on wether clients can find reasonable UX for it.

Despite not supporting wildcards, we may end up wanting to allow some kind of "all" special value.

HarHarLinks · 2026-06-26T11:32:53Z

+  3. `servers` mapping [Server Names][servername-format] (default `{}`)
+
+While homeservers SHOULD follow these defaults, operators and implementations MAY override them where appropriate.
+For example, an operator may default `share_locally` to `true` in an organisation environment.


It would be reasonable for a server also to allow setting "share locally only", as well as disabling presence entirely as is possible today.

If so, this should be reflected in UX somehow. I.e. users on such a server trying to allowlist others would be pretty confused (and wasting their time) if there was no UI feedback (e.g. that part of UI disabled).

HarHarLinks · 2026-06-26T12:34:59Z

+   Servers SHOULD only include local users that the sender shares at least one room with.
+4. Include all **users listed as `"allow"`** in the user's `m.presence.sharing` configuration. Servers SHOULD only
+   include users from this list that the sender shares at least one room with.
+5. Exclude any **users listed as `"deny"`** in the user's `m.presence.sharing` configuration.


Would it not be reasonable to also exclude ignored users?

We opted against doing so with the rationale that ignoring users, by design, prevents you from seeing their events but not them from seeing yours. Ignored users are supposed to be one-way, so we're keeping with that theme.

HarHarLinks · 2026-06-26T12:38:29Z

+users, denied users) could be sent over federation. This proposal uses sender-side user resolution to avoid sending
+a "block list" to third parties, and to keep resolution consistent with the sending homeserver's state.
+
+### Entity Selection Affordances


Practically, the assumption is that it's not worth including whole servers because either they are small servers with few users you might as well add manually, or against the goal of the proposal to limit to whom my presence gets exposed. Idk this might be worth adding or not.

HarHarLinks · 2026-06-26T12:40:16Z

+Only allowing users to follow hints via `"allow"` means a `"forbid"` hint state explicitly forbids presence sharing
+for all users of a room. This allows room administrators to retroactively *disable* presence sharing for rooms as
+they grow; for example, if a previously private room grows to be public and contain many members, a room
+administrator may wish to disable presence sharing in the room.


Hm, why would an admin do that? I don't think room admins will want or be able to make judgements on the performance (?) of participating HS.

Performance, or perhaps privacy concerns, or to limit exposure temporarily if users are spamming inappropriate status messages, or if they just don't want presence to be shared in their room, etc.

HarHarLinks · 2026-06-26T12:48:33Z

+* Limiting the ability of users to share presence with rooms above a certain number of members
+* Limiting the number of entities (or total recipient users) users can have in their presence sharing maps
+
+### Presence EDU Batch Sizes


matrix-org/matrix-spec#807

TheArcaneBrony · 2026-06-27T11:58:57Z

+### Presence Access
+
+Selective Presence *disables presence by default*. This may complicate future proposals that require publicly
+accessible presence information, and may change the way users interact with presence features. However, as
+previously mentioned, presence should not be public by default. A future proposal may address public, fetchable
+presence (see [Alternatives](#Alternatives)).


I feel like this may be in conflict with the expectations of users comming from other platforms, since the general behavior there is that presence is public with (partial) ability to opt out (eg. discord not allowing presence to be private beyond setting it to an "invisible" state, but allowing per-guild opt out of sharing rich presence info) - this is directly in conflict with the entire idea of using something like rich presence itself as an extension of your persona

I do not think it is fair to say that public presence is a general behaviour. There are several popular WhatsApp-style platforms where presence information is strictly limited to your contacts, or some other curated model. For platforms like Discord, a pubsub model is used internally, but with a looser mode of access control; the concept is similar to just adding rooms to the sharing map and removing them on request, although I would not advise this. We anticipate that a similar pubsub model will be used for the development of rich presence in the future.

Additionally, users can easily be taught. "You must share presence with who you want to see it" is not a particularly tough UI choice.

Additionally, users can easily be taught. "You must share presence with who you want to see it" is not a particularly tough UI choice.

I would caveat that with a gentle suggestion that we should prove this in implementation. It's not the first MSC where behaviors sounded easy on paper and were a nightmare to design for.

Signed-off-by: L Veneris <tyler@kludgecs.com>

Half-Shot · 2026-06-30T16:21:48Z

+A new [`account_data`] entry, `m.presence.sharing`, is stored for modification by clients and use by homeservers.
+
+This event contains four properties:
+* The boolean `share_locally` enables sharing presence with all users with mutual rooms on the local homeserver


Can you expand on why we don't just have:

"servers": { "my-local-server": "allow|deny" }

?

The section Alternatives / Entity Selection Affordances describes why we chose to forbid allowing entire servers in the servers map. We found there to be few real world use cases, and sending a full server allow list over federation (especially to large homeservers) would be difficult with the model we settled on.

Additionally, we anticipate few clients will actually utilize the servers map in their UX.

Further to the points given by @thetayloredman, providing "allow" for one special case of this map would make things harder for implementations in strongly typed languages. Having the type of this map be the enum "allow" | "deny" when "allow" is only valid for your local server would be unfortunate.

Half-Shot · 2026-06-30T16:23:17Z

+
+A new room state event is introduced, `m.room.presence_sharing`. This state event contains one field,
+`presence_sharing`, which is a string with two possible values: `"suggest"` and `"forbid"`. If the event is not
+present, the room is treated as though its value is `"forbid"` by default.


This would presently break the current presence model? How would users/server admins migrate, would they need to send state events to all rooms (twice, because of the unstable prefix?)?

Yes, rooms will all default to having presence disabled, and their administrators will need to send the state event to change it to suggest. Clients could choose to e.g. display a prompt in 1:1 rooms to ask the user if they would like to both enable the hint and add the room to their sharing map, but this behavior is not specified.

I would be interested in investigating if it is possible to specify further suggestions for this sort of "auto-migration" behavior primarily for DMs.

Half-Shot · 2026-06-30T16:27:30Z

+      <td>Yes</td>
+    </tr>
+  </tbody>
+</table>


meta note but this is hard to parse

What would the preferred formatting be? I formatted this as it is formatted in the specification itself, because I didn't see a style guide in the repo documents.

Half-Shot · 2026-06-30T16:30:27Z

+It was proposed that a user's `m.presence.sharing` `"rooms"` configuration could live in room account data, but
+this proposal opted against doing so to avoid fragmenting the configuration between different sources.
+
+### Fallback Behaviours


Is this still part of the parent Alternatives section, if so this is a bit confusing

Half-Shot · 2026-06-30T16:34:31Z

+  The `"allow"` state MUST NOT be specified for entire homeservers under the `"servers"` object.
+
+Servers MUST treat users without `m.presence.sharing` in their `account_data` as though the default values were
+specified.


I think it's going to be too radical a change to go from sending presence everywhere to not sending any without any user interaction. This will almost certainly break some workflows that are relied upon today.

Can we instead at least introduce a capability or some measure that allows servers to tell clients they are now using selective presence? I think more discussion about how folks migrate needs to be present in this proposal.

I would suggest that we implement this as a capability, since it would make no sense for clients to show the selective presence UI on servers without it regardless. I can see this being a problem for bots and appservices, which may want their users to know if they're online or not, but other than that it is hard to consider how people might migrate workflows without knowing what those workflows are. On the other hand, I am wary of falling into an XKCD 1172 situation.

After some discussion with Ginger, I must ask, what would the purpose of introducing a capability be? It is my understanding that capabilities are for features that are implementation dependent, i.e. optional for a given spec version. Selective Presence is not intended to be an optional feature. It is a whole replacement of the existing presence broadcasting model. Clients already have a way to tell if a server is using Selective Presence in this regard, through GET /_matrix/client/versions.

…room upgrades Signed-off-by: Logan Devine <logan@zirco.dev>

Signed-off-by: L Veneris <tyler@kludgecs.com>

thetayloredman and others added 2 commits June 25, 2026 13:56

Become MSC4495

5db3267

Signed-off-by: Logan Devine <logan@zirco.dev>

thetayloredman changed the title ~~MSCXXXX: Selective Presence~~ MSC4495: Selective Presence Jun 25, 2026

turt2live reviewed Jun 25, 2026

View reviewed changes

Polish language for federation sections

4534876

This also fixes a rogue "populated" in the EDU updates, which conflicted with the case where there are updates but not for a particular remote. Signed-off-by: L Veneris <tyler@kludgecs.com>

HarHarLinks reviewed Jun 26, 2026

View reviewed changes

TheArcaneBrony reviewed Jun 27, 2026

View reviewed changes

Address phrasing feedback from @HarHarLinks

bee4268

Signed-off-by: L Veneris <tyler@kludgecs.com>

thetayloredman mentioned this pull request Jun 29, 2026

Add experimental support for MSC4495: Selective Presence ruma/ruma#2521

Closed

Half-Shot reviewed Jun 30, 2026

View reviewed changes

Comment thread proposals/4495-selective-presence.md Outdated

Half-Shot reviewed Jun 30, 2026

View reviewed changes

Comment thread proposals/4495-selective-presence.md

Half-Shot reviewed Jun 30, 2026

View reviewed changes

Comment thread proposals/4495-selective-presence.md Outdated

Half-Shot reviewed Jun 30, 2026

View reviewed changes

lveneris and others added 7 commits June 30, 2026 19:06

Rename del -> delete

10aca0a

Add rationale for prohibiting globs

0d415c1

Add note on servers respecting users' exclusion lists

098d72b

Update example m.presence EDU for del -> delete

2950635

Recommend m.room.presence_sharing as a transferable state event in …

671d256

…room upgrades Signed-off-by: Logan Devine <logan@zirco.dev>

Add m.selective_presence Client-Server capability

7cad1a5

Revert 'Add m.selective_presence Client-Server Capability'

d1ef8dd

Signed-off-by: L Veneris <tyler@kludgecs.com>

Clarify defaults behaviour for m.presence.sharing

181df09

Signed-off-by: L Veneris <tyler@kludgecs.com>

Uh oh!

Conversation

thetayloredman commented Jun 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

HarHarLinks Jun 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lveneris Jun 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

HarHarLinks Jun 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

thetayloredman Jun 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lveneris Jun 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

thetayloredman commented Jun 25, 2026 •

edited

Loading

HarHarLinks Jun 26, 2026 •

edited

Loading

lveneris Jun 27, 2026 •

edited

Loading

HarHarLinks Jun 27, 2026 •

edited

Loading

thetayloredman Jun 30, 2026 •

edited

Loading

lveneris Jun 30, 2026 •

edited

Loading