MSC3575: Sliding Sync (aka Sync v3)

[kegsay]

Rendered

Impl

Preview: https://pr3575--matrix-org-previews.netlify.app

[MadLittleMods]

What should happen for invite rooms?

If we copy Sync v2, then the invite room will only have invite_state (no timeline events, limited, prev_batch token, or required_state).

Perhaps we could make the rooms more uniform regardless of membership though. The hard case is how these fields should be set in cases where the user's room membership is invite with shared/joined history visibility where they can't see any timeline events until they join.

Where should the prev_batch token be pointing to? If we do it just like other rooms, we paginate up to the timeline_limit, then all of those events are filtered out (because we're not joined yet) and the prev_batch token points to a place before those events that we never saw. And then potentially when we join, we will miss those events depending on what the client does.

If we change the scenario to a room with world_readable or invited history visibility where timeline events would be returned when you are invited; The answer is timeline events are returned, limited is set respectively, and prev_batch points to the first event to continue paginating (no problems there).

For ban/leave, we can just query for timeline events up to the point where they were banned/left (no problem here either).

---

First discussed in element-hq/synapse#17320 (comment)

[MadLittleMods]

I think I found the distinction for why we don't do this: local vs remote room

For a room where another local user is already in the room (which means we already have the info necessary on our local server), this kind of thing makes sense to me. Being invited to a room probably means you should have access to the room (access to the full state of the room and events based on history visibility) (no security concern). Stripped state makes more sense for knock rooms where you don't have access yet.

But the problem comes when you're the first one on your server to be invited to a new room over federation. When you receive a federated invite, you only have access to event.unsigned.invite_room_state so that's all that you can return to the client. You would have to go through the make_join/send_join process to start participating in the room and query more info.

So it makes sense just to do the same thing for all invite rooms, just return stripped state.

[MadLittleMods]

Related to matrix-org/matrix-spec#380. As an example, when someone is invited to a room, we don't even have the heroes necessary to calculate the room name if the room doesn't have m.room.name set.

This was solved for partial-joins via MSC3943

[MadLittleMods]

Instead of returning stripped state for heroes, we could simply return the User ID's of the heroes like Sync v2 (see m.heroes) and return the full membership event in required_state like we're already doing for $LAZY-loading room memberships.

Related to #3575 (comment) around making rooms more uniform regardless of membership.

[MadLittleMods]

What use case is include_heroes useful for?

heroes will already be populated when the room doesn't have a m.room.name set. And you can specify $LAZY-loading room members to get relevant members in the room.

[bnjbvr]

And you can specify $LAZY-loading room members to get relevant members in the room.

Ideally, the list of members used for heroes should be deterministic, i.e. not change from one initial response to another (assuming the list of members hasn't changed in the room, of course). Using $LAZY would give you a list of some members, but it's unclear it'd still be the same, all the time. For what it's worth, the Rust SDK just reflects the heroes when it gets them from the server-side with no extra computation, otherwise it'll try to use the room members' information (get the display name + avatar, etc.)

[MadLittleMods]

heroes are used to calculate the room name so being deterministic is useful so the room name doesn't change that much. heroes are already automatically returned when the room doesn't have m.room.name set. Since this behavior is already built-in and automatic, this include_heroes option isn't necessary for room name calculation.

Are heroes used for anything else? If not, then this option isn't necessary

---

Displaying a few avatar bubbles to preview some of the room members could be useful:

A similar effect could be achieved by $LAZY-loading room members and fetching enough timeline events. heroes could also work but it will always only be up-to 5 members and won't reflect who's currently chatting if it's a big room. You could also fetch all members in the room by using required_state: [["m.room.member", "*"]] but can be a bit burdensome to parse in very large rooms. This use case might be better served by a specific extension to be able to specify the number of members you want to fetch and how you want them sorted.

[bnjbvr]

Are heroes used for anything else? If not, then this option isn't necessary

They're exposed to the EX apps at least, which use those to compute a hash that serves to determine a unique color for a room's visual entry in the room list. I think that color will also match what EW displays, since it's based on the same algorithm. That computation (be it done by the SDK or the EX apps themselves) requires the heroes to always be present.

[MadLittleMods]

Thanks for sharing another reference @bnjbvr 🙂

use those to compute a hash that serves to determine a unique color for a room's visual entry in the room list

Why not just hash against the room ID?

Feels like the room color would change over time as the heroes will shift around until 5 people are in the room and will shift as people leave the room.

As far as I can tell, Element Web just bases it off the Matrix ID (for users) and room ID (for rooms):

• useIdColorHash(...)
• compound-web -> src/components/Avatar/Avatar.tsx
• matrix-react-sdk -> src/Avatar.ts

That computation (be it done by the SDK or the EX apps themselves) requires the heroes to always be present.

For Sync v2, heroes is only present for join rooms. And in Synapse, they are only returned when lazy-loading and (there are membership changes or initial sync).

So the color will change yet again based on membership if heroes was taken into account.

Can you share a link to the code in ElementX for this?

[MadLittleMods]

Thanks for the extra clarification!

It appears that heroes are only necessary for DMs (or group chats), aligning perfectly with the server's automatic behavior of providing heroes when a room name is not specified.

This further supports the argument that a separate include_heroes option is unnecessary.

[pixlwave]

Does that mean we wouldn't get the heroes for the "Soccer Club" example in the screenshot above?

[MadLittleMods]

@pixlwave Correct

Either, we could include m.room.avatar being set in the criteria for automatically including heroes or as I mentioned before, these kind of use cases might be better served by a specific extension to be able to specify the number of members you want to fetch and how you want them sorted. This would cover whatever people come up with and have a need for.

Calculating the display name for a room is a specced process whereas these other heroes usages are a lot more willy nilly and app specific.

[bnjbvr]

(A small note: there are other clients than Element in the world, and we should also keep it flexible for these.)

[pixlwave]

Let me see if I can find out actual product requirements for this on our side.

[MadLittleMods]

To preface this: I'm on the side of not trying to calculate room names. Just leave it to clients to use the explicitly set room name or calculate it themselves via the heroes.

One thing, I'm not sure about is if the name field should strictly be the value from the m.room.name state event or whether we should also fallback to the m.room.canonical_alias. The existing spec currently says that heroes should be returned "if the room’s m.room.name or m.room.canonical_alias state events are unset or empty." so it might make sense to fallback.

[bnjbvr]

Agreed; calculing room names server-side is doomed to cause incorrect i10n (as a room name computed from heroes would look, for all languages, like "person A and person B"), and closes the door to customization options (even though that argument is feeble; the user value in being able to choose how many heroes are used for a fallback calculated room name would likely be quite low).

Re: fallback: I'd say no, let the clients implement this.

[MadLittleMods]

Should we just use the existing definition of stripped state?

Stripped state events can only have the sender, type, state_key and content properties present.