Skip to content
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.

Local alias will not transfer on room upgrade if the upgrader is not the one who sent it #6842

Closed
anoadragon453 opened this issue Feb 3, 2020 · 4 comments
Assignees
Labels
A-Room-Upgrades z-p2 (Deprecated Label)

Comments

@anoadragon453
Copy link
Member

anoadragon453 commented Feb 3, 2020

While transferring of local aliases on room upgrade is implemented, it will fail if the person upgrading the room was not the person who originally sent the alias.

MSC2432 improves things here a bit in that it will allow people will sufficient room permissions to remove m.room.alias events, specifically:

  • DELETE /_matrix/client/r0/directory/room/{roomAlias}: in this case, currently Synapse restricts its use to the user that created the alias, and server admins.

It is proposed to extend this to local users who have a power-level sufficient to send an m.room.canonical_alias event in the room that the alias currently points to.

Although technically one can configure a room in a way where you can send m.room.tombstone events, but not have permission to modify aliases. In that case perhaps you aren't allowed to upgrade a room?

Changing the mapping can be specially done by the homeserver during a room upgrade (ignoring the sender here). We can only do this for local aliases of course.

Note to self: we need to be careful that with room admins able to delete aliases, that the room upgrade code won't remove all the aliases in the room, while simultaneously only being able to transfer the local ones. Remote aliases should be transferred when a user on a remote server joins the upgraded room.

@ara4n
Copy link
Member

ara4n commented Feb 15, 2020

i just got bitten by this trying to upgrade #gnome:gnome.org, which failed to transfer its #_gimpnet_#gnome:gnome.org alias over, thus breaking bridging :(

@ara4n
Copy link
Member

ara4n commented Feb 17, 2020

...and again with #newcomers:gnome.org, except this is even worse, as synapse is now on 1.10 so you can’t even see how the alias has got broken.

@anoadragon453
Copy link
Member Author

Heads up that this will be a thing of the past in our new alias world, as the upgrading user will have PL100 and can copy m.room.canonical_alias events from the old room into the new room just fine, even if they aren't the one who sent it.

@anoadragon453
Copy link
Member Author

Seeing as that new world is now, this can be closed.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A-Room-Upgrades z-p2 (Deprecated Label)
Projects
None yet
Development

No branches or pull requests

4 participants