Matrix Presence v2 Logo Is Presence Fixed Yet?

No, but we’re making progress.

Today, presence is one of Matrix’s least-deployed core features. Even with efforts to improve implementations1, almost every major public Matrix deployment disables federated presence, citing privacy and performance concerns2.

The root problem is architectural. Today, Matrix servers distribute presence to anyone who shares a room with a user, even if the two users have never interacted. Small servers regularly send updates upwards of 100,000 times an hour3. This expense results in server operators disabling presence entirely, which in turn results in a poor user experience for the large public servers where it matters most.

The goal of the Presence v2 initiative is simple: make presence useful for users while reducing its cost to servers. We hope that through improvements, presence can be a valued feature available to many more Matrix users.

A group of community members including maintainers of the Continuwuity homeserver, have been working on a coordinated set of Matrix Spec Change proposals (MSCs) to dramatically reduce presence’s footprint on federation traffic, improve privacy, and better align presence with the social use case.

If you are interested in helping improve Presence for the Matrix community, please join us in #presence-v2:zirco.dev.

The Proposals

MSC4495: Selective Presence

Selective Presence substantially cuts down on the amount of presence data sent by requiring users to explicitly indicate which other users or rooms they want to share their presence with, rather than sending presence to all users that can see them. Alongside our other proposals, this will both create a new privacy model for presence and overall reduce how much presence data is sent.

Revised Social Presence

Revised Social Presence is a proposal to remodel presence information to better support social use cases, including overrides and a busy status. This proposal also makes major improvements in privacy, alongside fixing some long-standing visual bugs.

Formalized Presence Batching

Formalized Presence Batching is a proposal to reduce the load of presence on servers by altering how it is sent. By increasing the time-to-live of presence information and sending it in batches, we can reduce the number of federation transactions required to keep presence up-to-date.

Sliding Sync Extension: Presence

We are exploring a Sliding Sync (MSC4186) extension to reduce the amount of presence data sent to clients. This would allow clients to only receive presence for users they are actively viewing, resulting in reduced bandwidth usage and improved performance for clients.

Fetchable Presence

Finally, we are exploring a proposal to allow users to publish their presence data without sending it to every user who can see them. Instead, users would be able to fetch presence data for other users on demand, preserving existing presence workflows while reducing traffic sent unnecessarily.

Not affiliated with the Matrix.org Foundation or New Vector Ltd.
Last updated ago ().
This website is open source.

  1. Synapse has had a meta-issue open about improving presence performance for 5 years: #9478 ↩

  2. Since 2018, homeserver operators have had performance concerns related to presence, and even raised them as bugs in Synapse. #3971, #9339 ↩

  3. Based on a 2020 analysis of an Element deployment with 66 daily active users. Disabling presence resulted in a ~19Hz reduction in outbound federation transactions, or 68,400 fewer federation transactions per hour. ↩