Implement new alias semantics (MSC2432)

[richvdh]

We've got yet another idea for how to implement alias semantics, documented in https://docs.google.com/document/d/1NNDkobiFLeUkJtyj0H6qvKIedgvIkZnFKo78-03cGEk and MSC2432.

The task breakdown for now is:

• Update {PUT, DELETE} /_matrix/client/r0/directory/room/{roomAlias} to stop sending m.room.aliases events. Update DELETE /_matrix/client/r0/directory/room/{roomAlias} to check the alt_aliases in m.room.canonical_alias.
• Update POST /_matrix/client/r0/rooms/{roomId}/upgrade API to stop copying room aliases (and thus to stop m.room.aliases events). Update POST /_matrix/client/r0/createRoom to stop sending m.room.aliases events.
• Add a new GET /_matrix/client/r0/rooms/{roomId}/aliases API, which returns the list of aliases which are currently available on the local server. Accessible by any member of the room.
• Update /_matrix/client/r0/publicRooms to stop sending a list of aliases.
• Update Synapse to stop considering m.room.aliases events for room names
• Update {PUT, DELETE} /_matrix/client/r0/directory/list/room/{roomId} to check the sender's PLs against that required for m.room.canonical_alias instead of m.room.aliases
• Update PUT /_matrix/clent/r0/room/{roomId}/state to do validation on the alt_aliases in m.room.canonical_alias
• Update DELETE /_matrix/client/r0/directory/room/{roomAlias} to allow it to be used by local users with PLs sufficient to send m.room.canonical_alias events.

[richvdh]

Work for the future, for the record:

• create a room vNext which removes the special auth rules and redaction rules for m.room.aliases
• Undo filter out m.room.aliases from the CS API until a better solution is specced #6878 and filter out m.room.aliases from /sync state blocks #6884
• Extend GET /_matrix/client/r0/rooms/{roomId}/aliases to allow passing in the name of a remote server to query over federation.
• Add a federation API which can be called by servers with mods in the room, to request that an alias be removed

[clokep]

Before saying this work is done, @richvdh suggests the following:

I think we should do the following:

• create a room vNext which removes the special auth rules and redaction rules for m.room.aliases
• Undo filter out m.room.aliases from the CS API until a better solution is specced #6878 and filter out m.room.aliases from /sync state blocks #6884

I think the following should be punted until the need for them is demonstrated:

• Extend GET /_matrix/client/r0/rooms/{roomId}/aliases to allow passing in the name of a remote server to query over federation.
• Add a federation API which can be called by servers with mods in the room, to request that an alias be removed

though note that "removes the redaction rules" is dependent on me finally landing #6875

[clokep]

• Undo filter out m.room.aliases from the CS API until a better solution is specced #6878 and filter out m.room.aliases from /sync state blocks #6884

Note that these seem to implement MSC2261.

@richvdh confirmed over Matrix that we want to backout MSC2260, but MSC2261 needs to stay in. MSC2260 seems to be #6787, #6790, and #6794.

[clokep]

@richvdh and I are going to need to come back around to this to ensure we have a shared understanding of what code to back out an what needs to be kept.

[richvdh]

I've been getting myself hopelessly confused over the state of play here, by trying to rush things through. So let me try to set the record straight:

I think we should do the following:

• Undo filter out m.room.aliases from the CS API until a better solution is specced #6878 and filter out m.room.aliases from /sync state blocks #6884

These do not implement MSC2261, but rather were stop-gaps that were put in place to mitigate the abuse vectors until other things (such as clients not showing aliases events and/or the ability to redact aliases events (ie, MSC2261)) were in place. We're not there yet. Please disregard my earlier statements that they can be backed out.

• create a room vNext which removes the special auth rules and redaction rules for m.room.aliases

We should pull apart the two parts of this:

• "the special auth rules" refers to point 4 on https://matrix.org/docs/spec/rooms/v1#authorization-rules: "If type is m.room.aliases...". The reason to remove it is that, once MSC2432 is landed, m.room.aliases has no special meaning in the matrix protocol, and indeed those special auth rules hamper admins' ability to control spam going into the room.

  Note that we can't just change the auth rules without risking a split-brain scenario where different servers reach different conclusions about the state that should be allowed into a room: hence the need to introduce new room versions to implement it.

  This work has already been done for an experimental room version as part of the initial work for MSC2260, in Implement updated auth rules from MSC2260 #6787. So, there's not actually much to be done here, though we could consider renaming the experimental room version, or combining it with the next point to create a new experimental room version:

• "the special ... redaction rules" refers to the bullet point in https://matrix.org/docs/spec/client_server/r0.6.0#redactions "m.room.aliases allows key aliases." In other words, this is "Implement MSC2261". That MSC goes into more depth about the reasons and difficulty in doing so.

  In practical terms, it means updating the prune_event function in Synapse to have knowledge of which room version we are working with, which is what I was trying to achieve with Store room_versions in EventBase objects #6875 and its massive line of predecessors.

@richvdh confirmed over Matrix that we want to backout MSC2260, but MSC2261 needs to stay in. MSC2260 seems to be #6787, #6790, and #6794

yes he did say that but as above, #6787 actually needs to stay.

#6790 and #6794 really do look redundant: they are new special-cases for m.room.aliases events which, as per all the above, we are trying to get rid of. Let's back them out.

I think the following should be punted until the need for them is demonstrated:

• Extend GET /_matrix/client/r0/rooms/{roomId}/aliases to allow passing in the name of a remote server to query over federation.
• Add a federation API which can be called by servers with mods in the room, to request that an alias be removed

We should continue to leave these for now.

---

TLDR

We should:

• back out MSC2260: change the default power level for m.room.aliases events #6790 and MSC2260: Block direct sends of m.room.aliases events #6794
• Update the event redaction algorithm to remove the m.room.aliases special-case (ie, implement MSC2261); dependent on Store room_versions in EventBase objects #6875.

[clokep]

I believe all the work in this is done, minus the follow-up work:

I think the following should be punted until the need for them is demonstrated:

• Extend GET /_matrix/client/r0/rooms/{roomId}/aliases to allow passing in the name of a remote server to query over federation.
• Add a federation API which can be called by servers with mods in the room, to request that an alias be removed

And potentially #7069

My inclination is to:

• Close this issue.
• File a follow-up for the punted work.
• Handle the /publicRooms changes in /publicRooms should consider alt_aliases for returned aliases #7069 if we're going to do that.

[clokep]

See #7101 for the follow-on work.