Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Space rooms silently dropped over federation due to outdated via values. #1467

Open
AndrewRyanChama opened this issue Mar 15, 2023 · 1 comment
Labels
A-Client-Server Issues affecting the CS API wart A point where the protocol is inconsistent or inelegant

Comments

@AndrewRyanChama
Copy link

In the current spaces spec, the room alias of space rooms as well as suggested via servers are stored in the metadata. In order to join or fetch information of a room over federation, the user's homeserver which is not participating in the room must find another homeserver which is already participating in the room. This is done using the via attribute, which stores a list of homeservers that are likely to be participating in the room.

If these via servers are out of date, when the client calls /hierarchy to get information about the space rooms, the homeserver will be unable to fetch information about those rooms, and silently drop them from the response. This means that the user sees fewer rooms than intended in the space, with no sign that anything is wrong, and cannot realize the problem without getting information through side channels.

The problem is that the via servers are extremely likely to end up out of date, because there is no way to update them in current implementations of matrix clients. This has led to degraded experience of current users over federation who want to join spaces.

I think a mitigation MUST be specced and implemented, or else users over federation will face and increasingly broken spaces experience as time goes on.

A possible mitigation could include the changes:

  1. The space admin needs a way to "refresh" the via links so that they're up to date
  2. The user viewing the space should be displayed an error, so he knows that he's missing out on these rooms. Then he can badger the space admin to fix it.
@AndrewRyanChama AndrewRyanChama added the improvement An idea/future MSC for the spec label Mar 15, 2023
@turt2live turt2live added wart A point where the protocol is inconsistent or inelegant A-Client-Server Issues affecting the CS API and removed improvement An idea/future MSC for the spec labels Mar 15, 2023
@clokep
Copy link
Member

clokep commented Mar 15, 2023

the homeserver will be unable to fetch information about those rooms, and silently drop them from the response

I think this is only an issue if the homeserver is not in the room, correct?

It does somewhat feel like dropping them might be unintended, but I don't think clients would be able to do anything useful with the room ID anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Client-Server Issues affecting the CS API wart A point where the protocol is inconsistent or inelegant
Projects
None yet
Development

No branches or pull requests

3 participants