MSC4259: Profile Update EDUs for Federation

[tcpipuk]

Rendered

Signed-off-by: Tom Foster tom@tcpip.uk

---

Known Implementations:

• Servers:

[Half-Shot]

Some early thoughts.

[turt2live]

Implementation requirements:

• Server(s)

[tcpipuk]

Following a conversation with @Half-Shot in Matrix, I've given this a rewrite to use EDUs rather than a pull-based sync mechanism.

I considered proposing a subscription system and/or other metrics, however EDUs are not really designed for this and more thorough interest/permissions systems are intended in other more thorough solutions such as "rooms as profiles".

[anoadragon453]

A discussion on performance will inevitably come up on this MSC, so I'd like to start that up here (and see the MSC itself address it).

Presence Performance

Many reviewing this MSC will immediately think of the performance problems that
plague the Presence
feature.

The Synapse homeserver's implementation of presence works via the following:

1. Presence information can be set by the client, but the server will use
   requests such as /sync and read receipts to determine if the user is
   "currently active" or when they were last active.
2. Presence information is shared between all users who share a room.
3. Online user's presence state is changed to "idle" if they are not currently
   active and their last active time was >5min ago. They are set back to "online"
   when they make a relevant request.
4. When a user joins a room, their presence information is sent to other users,
   and they receive presence information about all other users in the room.

From 2020 data, Element observed in a publicly-federating customer's deployment
that a homeserver with 66 daily active users saw:

1. ~16Hz total (local and remote) presence updates
2. ~3Hz coming from remote servers
3. ~1.5Hz of updates proactively being sent to clients and other servers.

The majority of CPU usage was going towards sending federation transactions
(which dropped from ~20Hz to ~1Hz after disabling presence). Spikes occurred
when a local user joined a room, which involved sending presence to every server
in the room, and receiving presence for every server in the room.

They also of course occurred whenever a user - that was in rooms with many remote
servers - updated their presence.

Much of this can be optimised through implementation and protocol changes.

Perhaps we could weave presence information into /{make,send}_join, or have a
separate, single call to bulk push and receive presence information for all
users in the room that belong to a given homeserver.

Implementations can spread updates to different servers out over time,
preventing many transactions being sent in parallel overloading the homeserver.
They can also rate-limit and "debounce" updates (ignoring some that appear in a
quick succession). They can optimise their HTTP clients so TLS setup costs are
light on CPU resources.

I still think profile fields hold value in their functionality over presence.
But similar optimisations can likely be applied to both features.

Profile Field-specific quirks

That being said, profile updates will generally be much less frequent than
presence updates in general. Profile fields make it easy to set different
rate-limits/debouncing logic for each field ID, e.g. you could limit m.call
updates much more strictly than m.music. Each field has its own traffic
patterns to consider.

I also think limiting who can see which profile will significantly cut down on
the traffic. A mechanism for allowing anyone to see your avatar/displayname, but
only friends seeing your current song, would go a long way. Presence didn't have
such a granular level of user-controlled recipients. This is best handled in a
separate MSC.