Federation of Homeserver Discovery

[Mathias-g]

Feature: Enabling sharing of homeservers through federation.

The homeserver federation is currently quite fragmented, when people on one homeserver want to join rooms on another homeserver they need to know about the homeserver, and know the URL, and then manually go in and select the homeserver they want to display rooms from in room discovery, this is not very user friendly.

One possible way of implementing a solution to this would be to allow homeserver owners to maintain a "default homeserver list" of servers they want displayed to their users, as well as a "homeserver follow list" of homeservers whose default homeserver lists they want to append to the homeserver list users receive in Element (minus duplicates). Element would get the list of homeservers from the homeserver it is connected to. Homeservers blacklisted by the homeserver you are on would not be shown of course.

Each homeserver in the "default homeserver list" could have a description string as well as a homeserver avatar, which can either be defined by the homeserver owner, or if N/A could be pulled directly from the homeserver that is linked to.

You could also do the same thing with homeserver blacklists, such that server blacklisting is federated too, perhaps with a reason listed for why a server is on the blacklist.

(On this same note, the server dropdown in element has to be ditched for a different UI, when you have many servers it is awful, a much better solution would be a filtering mechanism where the room discovery contains the rooms of all servers you have selected). On this note it would also be useful to have a setting for each homeserver in the default homeserver list where you can define if the server should be enabled in the filtering from default or not, that gives homeserver owners granular control over which servers' rooms will be in the room discovery by default. It should also be possible perhaps for a homeserver owner when they add homeservers to the "homeserver follow list" to define there whether the homeservers listed in the followed homeserver's default homeserver list should inherit filtering from that list, or whether they should all be enabled, or disabled.

Lastly, it would be good as well to make it so that each user could maintain a list of homeservers themselves, as well as a blacklist and follow list, this could work exactly the same as the aforementioned. You could even make it possible for users to follow either other users homeserver lists/blacklists, or for homeservers to follow users lists/blacklists.

In summary, this solution lets homeserver owners add all the homeservers they want their users to know about, and to share/follow this list of homeservers with other homeservers, making the matrix homeserver ecosystem less fragmented, and it solves a UX problem with searching through rooms in Element when you have multiple homeservers you are connected to.

Hope this makes sense, cheers!

[kevincox]

I would probably make more sense to provide a list of recommended spaces. Or even a space of spaces. In fact https://github.com/matrix-org/matrix-doc/issues/3196 discusses replacing the homeserver directory with a space which would allow all of the features that you mention here.

[Mathias-g]

That seems like a bad naming convention, homeservers are a different thing than the rooms, spaces and users on them, calling servers spaces sounds like an awful idea to me @kevincox. It will make it a lot harder for end users to understand what they are doing when they choose a homeserver.

[MTRNord]

I am wondering: isnt this a Feature that only exists on Element Web? And that has a config a Person hosting it can Set. Why would this need to happen on the protocol Level? Or am I missing something?

[Mathias-g]

Exactly right @MTRNord, it currently is only a feature in element, but it really should be supported on the spec level, because when its only in element it doesn't port across when switching apps, it also isn't easy for new users to find all the servers they want to connect to, and if someone connects to my homeserver from the native app or mobile app, there is no way for me to automatically deliver a list of servers to the user. The only way at the moment if I wanted to include such a list would be that I host a web version of element where I have added them, or if I want native apps I would have to roll and maintain my own version of them and get them onto app stores and whatever else. The ecosystem is very fragmented right now because of the lack of support on the servers and between servers in the network.

[kevincox]

I'm a bit confused what you are looking for then. Why would a user care about homeservers? They are basically an implementation detail for most use cases (other than possibly where they convey some trust due to closed registration, but that is more a thing about users than homeservers). It seems like most of your concerns are around finding interesting rooms to join. That is exactly what a space is for so I would rather reuse that feature than expand the current homeserver directory with its many limitations.

[MTRNord]

I'm a bit confused what you are looking for then. Why would a user care about homeservers? They are basically an implementation detail for most use cases (other than possibly where they convey some trust due to closed registration, but that is more a thing about users than homeservers). It seems like most of your concerns are around finding interesting rooms to join. That is exactly what a space is for so I would rather reuse that feature than expand the current homeserver directory with its many limitations.

I think the issue here is specific to how the room dir works. The room directory in matrix is bound to homeservers. So you need to speak to matrix.org to get their rooms. Element web has a dropdown where a user can add their server for this. The request is basically to allow homeserver admins to suggest other servers. It would be probably helpful for less tech users to fond more rooms as those wont be able to use that dropdown most likely.

[Mathias-g]

Yes, that is correct @MTRNord, but it is a little more than that, it is also that there isn't any way at the moment for knowledge of homeservers to easily propagate through the network. So, even if you add the ability for homeserver owners to maintain a list of other servers they want to display to their users, that knowledge isn't spread to other server owners automatically. This is what the follow function would be for solving.

[MTRNord]

Yes, that is correct @MTRNord, but it is a little more than that, it is also that there isn't any way at the moment for knowledge of homeservers to easily propagate through the network. So, even if you add the ability for homeserver owners to maintain a list of other servers they want to display to their users, that knowledge isn't spread to other server owners automatically. This is what the follow function would be for solving.

So you want also that server X also announces its presence of existing to server Y? If thats the case this is maybe a privacy issue if the server owner of server X doesnt want to be displayed directly to users of server Y 🤔

[Mathias-g]

I would like other servers to be able to follow my list of servers to append to what is sent to users on their own server. I don't see any privacy issue, if a server owner does not want people from other servers in general or only specific servers to be able to join his server or view his rooms, there are many ways to configure your server to accomplish that.

[kevincox]

The room directory in matrix is bound to homeservers. So you need to speak to matrix.org to get their rooms.

Exactly, and turning the room directory into a space would solve this issue as you can sync it between homeservers. And your homeserver could add another homeserver's "room directory space" as a subspace in its "room directory space" for discoverability.

[Mathias-g]

When you have a hammer everything looks like a nail I guess. In my opinion the spaces solution is inelegant, it mixes up terminologies, making it harder to understand for end users.

[ShadowJonathan]

The far-future goal is got matrix homeservers to go away more or less entirely, it'll be good that concepts are (as) decoupled from those server (as they can be). Spaces basically abstracts over homeservers and users alike, while not being pinned down to a single server like a room list.

This can create much more organic social structures than the pervasive "server" previously did. I know that homeserver discovery akin to Mastodon would be a nice thing, but to confuse it with Spaces would be missing the point, imo. See matrix-org/matrix-spec#830, as mentioned above, for more on this.

[Mathias-g]

Am I to understand this as the position of the entire team? If yes I guess I have to reconsider using matrix at all.

[ShadowJonathan]

No, I am not a part of the team, this is what I've gleaned regarding high-level intentions. If you want to get in contact and get a straight answer, I suggest joining #matrix-spec:matrix.org and asking directly.

[kevincox]

What differences do you see between this directory and a space that makes you think that a space is overkill. Have multiple backend implementations for similar concepts adds complexity to both users and implementations. I would like to reuse what already exists unless we have a good reason why it would be suboptimal to do so.

[ShadowJonathan]

I think a directory is seen as "simpler", as a space would require more intermediate layers.

Imo this is a fallacy, as it'll prefer centralisation and simple REST over distributed and flexible rooms, rooms right now may be a bit bloated (per effect of server, client libraries, or else), but focusing on making them slimmer is exactly what the focus should be, to make them more viable for more use-cases.