Support thirdparty network queries over federation

[deepbluev7]

Suggestion

Currently you can query information about users, locations and protocols using the /thirdparty endpoints. This however only works for bridges/appservices running on your own homeserver, which makes the feature inaccessible to most users.

It would be nice if I could query if a user is from a bridged network and show an appropriate icon for that. I.e. show which users are irc users, so that I can take care to reply in the right format to them.

Additionally it would be nice to be able to query where a room is bridged to.

It seems a bit tricky however to define, what server to send the request to. A request about a user makes sense to send to the users homeserver, but what about a location query for an alias?Asking the server that controls the alias makes some sense, but will give you a partial view. And I have no idea at all how a query for supported protocols would look like.

[deepbluev7]

Related: https://github.com/matrix-org/matrix-spec-proposals/pull/2346

[Half-Shot]

Honestly, my pretty deeply held view on this is that we should scrap the thirdparty endpoints and replace them with Matrix rooms + RPC events for quite a few reasons:

• The endpoint has never worked over federation (this).
• The endpoint has never been able to tell which user is requesting the information (this is a given with Matrix events). It
• We can scrap a whole load of AS API bloat (and avoid building more federation APIs).
• Encryption comes for free.
• Arguably, most users who want to query a AS/bridge will already have a DM room with them for puppeting / information or otherwise. We should probably not make these rooms bloat the room list, but arguably we should have provisions in Matrix to treat some rooms as data channels and not conversational (i.e. spaces).
• The relationship between user and bridge becomes more direct. It allows the user to precisely know which bridges on which domains they are talking to (and can therefore determine where the data is going. It's no longer just "query a IRC bridge on matrix.org". This might sound like a minor point, but it's really strange how we ask users to trust and verify a bridge bot user to puppet ourselves, but the channel for doing search requests is a different shape entirely.
• Nebulous but: Arguably fallbacks for non-supporting clients become easier to build if you're already using a Matrix room as a data channel.

There are downsides, such as your query response lingering in the room forever (hence, crypto). I suspect when we finally build out ephemeral messaging for the location sharing project, this can be put to bed though.

[bleonard252]

@Half-Shot I do think having a flag in m.room.create or somewhere similar that tells clients that a given room isn't for human consumption would be nice. It would be useful for other MSCs as well, for use cases like spaces, calls, Third Room, or game clients, to tell clients not to show a particular room type if it doesn't know how. I suppose the idea would be, if it can't reasonably be represented like a conversation, (micro)blog, forum, or similar, use the "data room" flag to specify "hide by default."

If there already is an MSC for it, point me in that direction. If not, I'd be glad to draft one \:)

"m.data_room": true, // hide this room by default

[turt2live]

Room types are already in the spec: https://spec.matrix.org/v1.3/client-server-api/#types

[bleonard252]

Room types are already in the spec: https://spec.matrix.org/v1.3/client-server-api/#types

The spec does not indicate what should be done with room types that a client doesn't know about. Right now, unknown room types appear to be shown on most clients as regular rooms; I'm suggesting a "hide-by-default" marker to use where falling back to a conversational view does not make sense.

I'll take this into Matrix instead of derailing this issue further.