/publicRooms should consider alt_aliases for returned aliases

[bwindels]

Currently, Synapse only returns the canonical alias for returned rooms from the /publicRooms endpoint. alt_aliases in the canonical alias event should also be considered to return in the aliases field.

Before the changes for MSC2432, Synapse would also return local aliases in the aliases field in the /publicRooms response. This had the nice property of making rooms joinable over federation through the room directory without moderator intervention. Should we consider to return a (subset) of the local aliases if no canonical alias or alt_aliases have been set for a public room? Spam should be easily avoidable that way by just setting a canonical alias.

[clokep]

Related to #6898 .

[neilisfragile]

This seems sane to me, I don't believe the behaviour was deliberately changed.

[bwindels]

fwiw, we've mitigated this somewhat on riot-web by passing the server we've requested the public rooms for as the server_name param to the /join request, so it will at least try that server if needing to join over federation. The above would still be nice to have if that server is down though.

[clokep]

Would this need additional spec changes?

Implementation wise, I think this would be pretty straightforward.

[richvdh]

the intention, as mentioned in https://docs.google.com/document/d/1NNDkobiFLeUkJtyj0H6qvKIedgvIkZnFKo78-03cGEk, and iirc discussed somewhere in the comments, is that /publicRooms should not return the addtional aliases.

This comes back to the fact that you can't rely on the aliases listed in a room event (be it m.room.aliases or m.room.canonical_alias): by the time you see them, the alias might have been repointed.

fwiw, we've mitigated this somewhat on riot-web by passing the server we've requested the public rooms for as the server_name param to the /join request, so it will at least try that server if needing to join over federation.

That is the correct way to do it, imho.

The above would still be nice to have if that server is down though.

if the server is down, you wouldn't have been able to pull a room directory from it?

[bwindels]

if the server is down, you wouldn't have been able to pull a room directory from it?

I wasn't sure whether your local homeserver can cache the response from the other HS, but I guess that makes sense. Should the aliases field be removed from the spec then?

I'll close this one.

[richvdh]

Should the aliases field be removed from the spec then?

well, it's currently optional in the spec... I guess if a server impl wanted to return it, we shouldn't stop them?