m.room.aliases tries to be a list of possible aliases for a given room; useful
for discovering alternative routes into a room (for those already in the
room), and for educating users about how Matrix works by illustrating multiple
aliases per room. It also helps give a perception of the size of the network
(look how many people found it useful to set an alias for this room!).
However, it has problems:
- Anyone can create aliases for rooms, which are unilaterally added to
m.room.aliasesand cannot be removed by the room admin, allowing abuse. m.room.aliasescan get out of sync if server admins remove aliases from their server, or add new ones without updating them.room.aliasesfor that room.
We let users define aliases for their rooms, but empower room admins to curate
the alisaes which are advertised in m.room.aliases. This means:
- Anyone can create/delete aliases in their server's room directory (modulo any implementation-specific restrictions the server imposes)
- If the user has the PL required to set the m.room.aliases event for the
room, these aliases get added to the room's state by the server on behalf of
the user. Users can only set aliases event(s) for their own server.
- (The user could also try to set this manually and deliberately desync the event, which is considered acceptable risk. In theory the client could weed these out by refusing to display aliases which don't point to the room. In practice, we could consider malicious aliases like these to be abusive and solve this problem via moderation, as per below).
- To moderate the alias list, admins can redact malicious aliases, or set the
PL for
m.room.aliasesto prevent randoms publishing addresses to their rooms in the first place. - When an alias is deleted on the server directory, that server should remove
it from the
m.room.aliasesevent (on behalf of that user) to keep the aliases event in sync with the directory.
okay. i'll try to provide my feedback on 2260 then to get us aligned