Mini proposal for fixing aliases (MSC2260bis)

msc2260bis.md

Mini proposal for fixing aliases

Problem

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.aliases and cannot be removed by the room admin, allowing abuse.
• m.room.aliases can get out of sync if server admins remove aliases from their server, or add new ones without updating the m.room.aliases for that room.

Solution

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.aliases to 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.aliases event (on behalf of that user) to keep the aliases event in sync with the directory.

Sadly I don't think github lets you do inline comments on gists, so...

It sounds plausible, but I think a key thing to my understanding of the proposal is that I'm not quite sure what you envisage the auth rules will look like. Are you suggesting that we remove the special-case on m.room.aliases and auth it as a normal state event, or something more subtle than that?

In other words, I'm not clear if you're proposing something different to (my) msc2260, or just looking to express it in a different way. That's probably my fault for failing to make msc2260 legible, but either way, I'm afraid I'm not quite following this.

Oops, sorry; i was focusing on the problem statement rather than the soln :S

• Leave the auth rule as is - we don't want users trying to declare aliases on behalf of other servers.
• Make setting the aliases subject to PL (if they aren't already) to stop randoms setting aliases if you don't want them
• Let aliases be redacted, so moderators can clean up any messes (whilst knowing this won't edit the actual room directories on the servers, but that's fine - m.room.aliases is a set of aliases which are advertised on a room, rather than the actual contents of a directory)

The last 2 bullets mean that you have the same moderation available to you as you would when stopping users posting abusive m.room.messages into the timeline: either you set a PL to gag them, or you redact the crap they post. This should be adequate abusewise.

as per #spec:

Leave the auth rule as is - we don't want users trying to declare aliases on behalf of other servers.

Make setting the aliases subject to PL (if they aren't already) to stop randoms setting aliases if you don't want them

It's the auth rule that means that m.room.aliases are not subject to PLs, so these two are in conflict

Can we not just change rule 4c to be a fall-through rather than an allow?

Currently it's:

4. If type is m.room.aliases:
   a) If event has no state_key, reject.
   b) If sender's domain doesn't matches state_key, reject.
   c) Otherwise, allow.

Yes, we can do that. That's equivalent to my proposal in MSC2260, with the added constraint that room admins cannot modify the aliases for a remote homeserver. That might be sensible, but I think it's still subject to all the issues at https://github.com/matrix-org/matrix-doc/blob/4d45afd2c53ce951502df742c5b76897a193de20/proposals/2260-change-aliases-auth-rules.md#potential-issues.

okay. i'll try to provide my feedback on 2260 then to get us aligned