Consider replacing the public rooms list with a server-wide space

[Half-Shot]

(This is likely more of an implementation detail than a spec issue. I've dumped my thoughts here as this applies to most server implementations though.)

This is mostly to reduce complexity, but it would be interesting to see the public room list become a single space for a server. The idea being that the room visibility API would instead just add rooms to a space under the hood, and the public room list API would simply check that space and return results based on the children within.

The advantages I can see to this mechanism are:

• Auth controls for who can add to the public room list are now just controlled via normal room authorization logic.
• The ability to make your room directory invite only, so only certain users can see the details in your rooms.
• Moderation of the room directory could be passed off to a bot, which can simply sit in the room and read new entries down sync, making appropriate decisions about who can read them.
• Users can subscribe to the space to add them to their directory list as we do today with account data.
• Appservice directories simply become child spaces of the main directory. The current spec doesn't provision for federated AS directories at all, so it also solves that problem.

[t3chguy]

This feels quite heavy on the client, the client today delegates the searching of the room directory to the server. Would you propose the Space Summary API gain filtering abilities to match that?

[deepbluev7]

I've been playing with that idea for a while too. In general I mostly like the moderation benefits. You can use a bot, delegate moderators, assign permissions, etc. Currently it is pretty hard to moderate the room directory, since you don't get updates for it, so you basically need to poll it manually. It would also allow users not on your homeserver to add rooms, so not everyone needs to have an account on matrix.org to make their rooms discoverable.

Additionally it would be very nice to be able to pin different room directories in your clients by just joining the space. Currently the different room directories are mostly added client side or in the client config.

[Half-Shot]

This feels quite heavy on the client, the client today delegates the searching of the room directory to the server. Would you propose the Space Summary API gain filtering abilities to match that?

This would propose keeping the existing room directory endpoints for the time being which would just use the space as a backing store, to reduce complexity on the server side and allow people to use the directory as a space, but that would not be the only mechanism.

I would expect the summary API would take a more prominent role though, perhaps gaining most of the features that the public room list API has today. (I assume most of the things you want to search for in public rooms also applies to spaces).

In summary I wouldn't expect clients would need to implement all the heavy work to read from the directory space, and this would be backwards compatible with what exists today. The advantage of this mechanism however is it allows us to reduce a lot of server duplication, and gives us quite a few features (outlined in the OP).

[Yoric]

A specific use case would be to have a Space for children-friendly rooms on matrix.org, moderated by the community. Users setting up their Element client for their children would be able to replace the public room listing with this Space.

Similarly, we could have a community-moderated Space for Spanish-speaking rooms and Clients could set it up by default for Spanish-speaking users, etc. (with the option to replace that Space, of course).

This definitely needs:

• the ability to search server-side;
• the ability to paginate results.

[kevincox]

The idea of the "default space" for looking up rooms is interesting, and it doesn't even have to be a "local space" (whatever that means) but there is one important function served by the server directory which is name lookups. For example I can join #matrix:matrix.org. We shouldn't have that resolve differently based on your "default space".

So a "default space" would be nice for browsing but not for alias lookup.

[kevincox]

Note: I am not really differentiating between directory and aliases even though they are somewhat separate in the protocol.

It would actually be cool if this was a full fledged space accessible to clients via the usual Space APIs. Ideally obsoleting the current directory APIs in favour of Space APIs. (It seems like most of the directory API features would be useful for Spaces) A benefit I see is that you could join and replicate the room directory. For example right now we are talking about the nixos.org homeserver and what would happen if it goes down. The answer is not much thanks to Matrix but one think is that #room:nixos.org references would break. Sure, they can be manually recreated but it would be really nice to have everyone in the space maintaining a local copy. It could even be possible to spin up a new server and mark the existing space as the "directory space" for the new server and be effectively back to full operation without any explicit backups.

Another nice feature would be allowing users on other homeservers to moderate the directory just by manipulating it like any other space. For example if I was elected to be an admin of the nixos.org Matrix setup I could add and remove rooms even though my account is @kevincox:kevincox.ca.

Basically I would like to decentralize room aliases and directories. I think a "default space" could obsolete the directory but a space (possibly the same one) could also be used to replace aliases.

[ShadowJonathan]

The idea of the "default space" for looking up rooms is interesting, and it doesn't even have to be a "local space" (whatever that means) but there is one important function served by the server directory which is name lookups.

To add onto this: maybe this "default space" could be added as a "recommendation" per-server similar to how element.io currently serves a "settings.json" file next to the web client, which dictates things such as branding and labs access, but also default rooms and a default homeserver. Maybe a homeserver could hint to a client that "recommended space", and then the idea of a "server list" might blur into that "default space", with some servers opting for their own curated space, some servers just picking another servers' space, and some not hinting any at all.