You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.
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.
The text was updated successfully, but these errors were encountered:
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 :(
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.
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: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.
The text was updated successfully, but these errors were encountered: