MSC2260: Update the auth rules for m.room.aliases events

proposals/2260-change-aliases-auth-rules.md

@@ -29,35 +29,41 @@ rules](https://matrix.org/docs/spec/rooms/v1#authorization-rules).
 
 ## Proposal
 
-We remove the special-case for `m.room.aliases` from the [authorization
-rules](https://matrix.org/docs/spec/rooms/v1#authorization-rules). `m.room.aliases`
-would instead be authorised following the normal rules for state events.
+1. We modify the special-case for `m.room.aliases` in the [authorization
+   rules](https://matrix.org/docs/spec/rooms/v1#authorization-rules), so that
+   `m.room.aliases` are subject to power-levels *as well as* the constraint
+   that the `state_key` must match the sender's domain.
 
-This would mean that only room moderators could add entries to the
-`m.room.aliases` event, and would therefore solve the abuse issue. However, it
-would increase the likelihood of `m.room.aliases` being out of sync with the
-real aliases.
+   In other words, we remove step 4c from the rules.
 
-TBD: are you still allowed to add rooms to the directory when you don't have
-the necessary power level? If so, presumably this happens without updating the
-`m.room.aliases` event. So:
+2. We also change the default `m.room.power_levels` event generated by
+   [`/createRoom`](https://matrix.org/docs/spec/client_server/r0.5.0#post-matrix-client-r0-createroom)
+   to give ordinary users the ability to send `m.room.aliases` events (ie, we
+   add an entry `"m.room.aliases": 0` to the `events` map).
 
- * Is there any mechanism for syncing the alias list if you are later given
-   ops?
+3. We prevent clients from sending `m.room.aliases` events via the `/state` (or
+   `/send`) APIs, to prevent users from removing listed aliases or generating
+   spam aliases without the relevant PL.
 
- * What if another user on your server has ops? What if Eve lacks ops and
-   secretly adds `#offensive_alias:example.com`, and then Bob (who has ops)
-   adds `#nice_alias:example.com`? How do we make sure that the offensive alias
-   isn't published by Bob?
+   TBD: alternatively: switch to [`m.room.alias`
+   events](https://github.com/matrix-org/matrix-doc/issues/2259), and make
+   sending such events an alias for the directory APIs.
 
-Server admins will continue to be able to remove entries from the directory
-even if they do not have the right to send the `aliases` event (in which case
-the `m.room.aliases` event will become outdated).
+4. We make it possible to redact the contents of `m.room.aliases` events, as
+   per [MSC2261](https://github.com/matrix-org/matrix-doc/issues/2261).
 
-It would also be logical to allow the contents of `m.room.aliases` events to be
-redacted, as per [MSC2261](https://github.com/matrix-org/matrix-doc/issues/2261).
+This means:
 
-## Tradeoffs
+* Anyone can still create/delete aliases in their server's room directory
+  (subject to local permissions restrictions).
+
+* If the user has the PL required to send an `m.room.aliases` event (ie,
+  normally), the server will generate such an event on the user's behalf.
+
+* Room admins can handle alias spam by redacting abusive aliases and/or raising
+  the PL necessary to add new aliases.
+
+## Alternatives
 
 Perhaps allowing room admins the ability to redact malicious `aliases` events
 is sufficient? Given that a malicious user could immediately publish a new
@@ -69,19 +75,33 @@ Or we could just allow room admins to issue new `m.room.aliases` events
 would work reliably in this case). However, that seems to suffer the same
 problem as above.
 
+Or we could just restrict the ability to send `m.room.aliases` to moderators
+(like any other state event). That seems like it would be overly restrictive in
+the aliases published, though.
+
 ## Potential issues
 
-1. This will increase the number of ways that `m.room.aliases` differs from
-   reality, particularly if we allow people to add entries to directories when
-   they lack ops in the room, but also when server admins remove entries from
-   the directory (currently https://github.com/matrix-org/synapse/issues/1477
-   could be fixed, but under this MSC it would be unfixable.)
+1. This does little to address the drift of `m.room.aliases` from
+   reality. Indeed, it would exacerbate
+   https://github.com/matrix-org/synapse/issues/1477.
+
+2. Unless we replace `m.room.aliases` with `m.room.alias`
+   (https://github.com/matrix-org/matrix-doc/issues/2259), there are problems
+   around delayed updates to the aliases list:
+
+   * Eve adds an offensive alias. She does not have the relevant PL to update
+     the `aliases` event, so this has no effect except to add the entry to the
+     directory, and it probably goes completely unnoticed.
+
+   * Later, Bob (who is on the same server as Eve, but has the PL to update the
+     `aliases` event) adds a new alias to the room.
 
-2. Often, all moderators of a room will be on one server, so much of the point of
-   `m.room.aliases` (that of advertising alternative aliases on other servers)
-   would be lost.
+   At this point, I am envisaging an implementation where the server will
+   automatically generate an `m.room.aliases` event, with Bob as the sender,
+   listing all of the current aliases for the room. In other words, other users
+   in the room will see "Bob added `#nice_alias` and `#evil_alias`".
 
-3. This would allow room operators to add 'fake' aliases: for example, I could
-   create a room and declare one of its aliases to be
-   `#matrix:matrix.org`. It's not obvious that this will cause any problems in
-   practice, but it might lead to some confusion.
+   An alternative impl is possible where the new `aliases` event is based on
+   the previous one and just adds the new alias; however that screams races to
+   me and (particularly once state resolution comes into play) I think it's
+   likely that the list is going to get out of sync.