We need a way to discover custom permalink prefixes.

[ara4n]

matrix-org/matrix-react-sdk#3500 is awesome, but currently relies on riot-web's config.json to find out what permalink prefix to use. this sucks for other clients (e.g. riot-ios or riot/android or others) which might connect to the server and need to know what prefix to intercept the links in-app.

We can't use matrix URLs for this given the use case for custom permalink prefixes is unfederated deployments, so instead we should specify a way via /info or similar to advertise the prefix that server recommends.

[KitsuneRal]

I think Matrix URLs would work here, had we a sort of "authority" part in them that would allow to explicitly specify the server from which a message is available. Something like https://matrix.to/#/unfederatedgateway.org/#unfederatedroom:unfederatedserver.org or, as already defined in my vapourware MSC, matrix://unfederatedgateway.org/room/unfederatedroom:unfederatedserver.org

[ara4n]

ooh, yes. how should the client know that "you must be directly connected to unfederatedgateway.org via CS API" for this to work though, versus "try to use this server to join the room over federation?"

[KitsuneRal]

I guess we already use ?via= for the latter, and this is more about routing over federation which probably shouldn't use the URL authority part as the entry point in the first place.

[ara4n]

so is the foo.com in matrix://foo.com/room the server your client is meant to be connected to, or the server your server is meant to connect to in order to join the room? the use case here is to define the server your client has to be connected to for the URI to work (for unfederated servers)

[KitsuneRal]

Exactly, and that's what I say: we already use ?via= in order to tell servers which other servers to connect to; while the unfederatedgateway.org part in my examples points to the server that the client has to directly connect to, because their homeserver might not be federating with it.

[KitsuneRal]

To illustrate: matrix:roomid/RoomId:example.org?via=example2.org or, respectively, https://matrix.to/#/!RoomIdh:example.org?via=example2.org tell that the client should pass example2.org to its "usual" homeserver so that the homeserver could join the room !RoomId:example.org and thereby make it available for the client. We already have this.

matrix://example2.org/roomid/RoomId:example.org or https://matrix.to/#/example2.org/!RoomId:example.org could tell that the client should discover the homeserver at the name example2.org (.well-known etc.) and connect to it directly (not via the "usual" homeserver) in order to join or peek the room !RoomId:example.org. An interesting question here is whether we should allow to specify multiple "authority" servers (mirroring the feature-richness of ?via=) - I consider this unnecessary because we talk about unfederated rooms/servers which I assume to be sort of centralised. But if, rather than considering example2.org the "authority", we just need some entry point(s) from the client to another, potentially decentralised, federation then this syntax doesn't work and we should find something else.

On yet another hand (and I'm getting carried away quite a bit here), if we talk about Matrix being a bunch of disparate federations then we might want to devise monikers for each federation, and those monikers could be "authority" names, with an assumption that clients somehow "know" how to find an entry point by a moniker (yet another naming service, yeah). That's really beyond the scope of this issue, anyway.

[ara4n]

this is actually breaking things quite badly on the mozilla instance, as people who connect via non mozilla-test.riot.im will see URL previews for pills.

[KitsuneRal]

Well, that obviously needs support on both ends - in matrix.to as well as in a client (because the client is tightly integrated with matrix.to). I don't think you can get away without changing the client to enable custom prefixes.

[ShadowJonathan]

On yet another hand (and I'm getting carried away quite a bit here), if we talk about Matrix being a bunch of disparate federations then we might want to devise monikers for each federation, and those monikers could be "authority" names, with an assumption that clients somehow "know" how to find an entry point by a moniker (yet another naming service, yeah). That's really beyond the scope of this issue, anyway.

A small comment or inspiration point for this, IPFS uses "dnslink" to tether a DNS TXT record to an IPFS resource, tangentially related to this aliasing usage, "pseudo-authorities" could be used to scope the query to a specific subsection, such as pinecone p2p, BLE, or site-local ipv6 multicast (pine.p2p, ble.p2p, ff05:[...])