Cheat Sheet for Matrix Sync in Raiden

raiden-matrix-sync-cheat-sheet.md

Matrix Sync in Raiden

This document is intended to collect Matrix sync information which are documented or not in the official Matrix Spec. Especially, how raiden treats the syncing process introduces some special behavior.

Blocking First Sync

Generally spoken the first sync delivers different results if a user already used this ID in Matrix or not. If already used the UserID is already part of the broadcast rooms (discovery, PFS, Monitoring). The Matrix Server will notice this and already send you information of the rooms you joined.

Events user receives:

• State Events of joined rooms
  • Membership Events such as joined, leave, invite. Only sends one event per user with the current membership state.
  • room states (Join_rules, power levels, canonical alias, room aliases, etc.)
  • no timeline events. They are filtered by the first sync filter. Hence no messages received.
• Presence Events
  • Presence Events are global. The Server collects presence events from all user_ids of interest. Which is all other users the user shares a room with.
  • Online Events are resend in a given interval
  • Offline Events are only received once
• Other Events
  • I found some data in the account_data key which should be neglectable

Filter

General Syncs - What to expect

In general syncs all events from broadcast rooms are filtered. In general we can expect the following events.

• Presence events
• rooms
  • invite -> If user is only invited. Limited information about the room passed. (e.g. no members info)
  • leave
  • join -> All events if user joined the room (First sync after join_room())
    • state events -> Events about the state of the room membership of partners, power levels, visibility, aliases
    • timeline events -> most recent state events and messages

Presence Events

Presence events are not room bounded. The server collects presence events for all users of interest. Which should be the partners sharing a room with the user. Presence events come only once if presence changed to offline. Online events come frequently with the sync.

Maybe important to note is that, despite presence events being global and coming independently of room filters, the user's metadata (such as displayName) comes on the respective join or membership events on the rooms we may have with the user. Therefore, for presences of users we share only the [filtered out] global rooms, displayName won't be available and may need to be explicitly requested (through /profile endpoint)

I think the search_user_directory also provides the displayname

Yes, it does, but afaik, it's called on start_healthcheck or so, not on presence events (which is when we should check for roaming users). Also, search_user_directory returns displayName, but not status (online/offline), requiring a /profile call on its own but for a different reason. This may/should also be noticed.

I looked into our code, and the presence events actually fetch the display name already if there is non in the displaychache. This case should already be handled.
Another interesting thing I found out: Despite being stated in the Matrix Spec that presence events might contain the displayname it is acutally not handled by the synapse call at all. This means, with the current synapse we are using there is never sent the displayname with the presence event.

Maybe important to note is that, despite presence events being global and coming independently of room filters, the user's metadata (such as displayName) comes on the respective join or membership events on the rooms we may have with the user. Therefore, for presences of users we share only the [filtered out] global rooms, displayName won't be available and may need to be explicitly requested (through /profile endpoint)

I meant that the profile endpoint is already used for fetching the displayname in the code

I know it's already done. Just mentioned because thought it'd be relevant to be noted in a Matrix Cheat Sheet ;)