Element-web: [Room Directory] Need to clearly show that protocols are children of homeservers.

[Half-Shot]

Description

Currently we have the dropdown look like this:

which doesn't clearly define that the protocol's are subgroups of the homeserver..especially since only the local homeserver shows protocol information.

We should either put the protocols into another dropdown to filter on (which allows me to also filter for one protocol across multiple homeservers) or increase the indent to make it more clear.

Honestly I'm more in favor of a smarter looking filter on the search which would let me grep across multiple servers for Discord rooms for example.

EDIT:

And we also don't distinguish protocols from instances which could be quite important e.g: All of the protocols listed are actually Discord guilds but you would never know that from looking at them.

[turt2live]

This sounds like an effective duplicate of https://github.com/vector-im/riot-web/issues/3769 (where the discovery was made that the protocol list has misunderstandings on how it works)

[lampholder]

Yeah, this dropdown is super confusing and is ripe for a rework.

A few clarifying questions as to what a replacement filter impl should/could _do_:

• Can homeserver A ask homeserver B for all of its public rooms? (I think YES)
• Can homeserver A ask homeserver B for all of its active bridges?
  
  
  
  • If it can, do those active bridges advertise a standardised bridgetype (IRC, discord, Slack)?
  
  
• Do we expect it to be a common use case for users to search for 'all the discord rooms, across every homeserver my homeserver knows about'?
• How expensive is that operation?

On the penultimate point, it feels like it would be nice to be able to ask for 'all the discord rooms accessible via "the matrix"', with dedupe for rooms that are multiply bridged. This filter could do some very good UX work to reinforce the scale and reach of Matrix.

[Half-Shot]

@lampholder I think this is definitely reaching into gdoc time, but yes I really want to improve the UX of how bridges are displayed. I want it to be immediately obvious that a room is a discord room and they can expect it to behave like one.

Can homeserver A ask homeserver B for all of its public rooms? (I think YES)

Yes, and we do that to an extent but we do NOT show protocols like we do locally which is the missing link for me. We should be showing the avaliable protocols of all homeserver's (unless perhaps the homeserver wants to keep a bridge hidden inside the local network, I'm not sure of use cases for this)

Do we expect it to be a common use case for users to search for 'all the discord rooms, across every homeserver my homeserver knows about'?

I think for quite a few bridges, there will be only one instance of a bridge for one community. I.e. for Discord we expect the clans/servers/guilds themselves to be hosting the bridge or talk to one of the big guys like Travis or Matrix.org to do it. So I expect the duplication of rooms for at least my bridges to be virtually zero, hence I feel the need to abstract away the idea of bridges behind hosted on someones homeserver to a degree.

How expensive is that operation?

At worst case you are firing a search operation against all the bridges of homeservers you have selected, which could be very interesting.

Can homeserver A ask homeserver B for all of its active bridges?
If it can, do those active bridges advertise a standardised bridgetype (IRC, discord, Slack)?

Currently we do this in the form of protocols. Bridges advertise their available protocols (which obviously is usually just the one), which defines the language of how the aliases are built up so you can show a sensible looking prompt to the user. It also allows you to show realms, so as you can see above my bridge is in several Discord guilds, so it shows a realm for each of these.

[uhoreg]

This sounds like an effective duplicate of #3769 (where the discovery was made that the protocol list has misunderstandings on how it works)

Also seems like a dup of https://github.com/vector-im/riot-web/issues/3932. It looks like this issue has the better labels, so maybe the others should be closed, and this one be kept.

It also might make sense to hide the "[m] Matrix" option when the user's HS doesn't bridge any other networks since it is redundant in that case.

[bpcurse]

It also might make sense to hide the "[m] Matrix" option when the user's HS doesn't bridge any other networks since it is redundant in that case.

And hide matrix.org if the HS is private and not federated at all

[t3chguy]

Riot has no way of knowing if your server is federated or not. You can remove matrix.org from your listing by omitting it from your config.json.