Add .well-known/matrix/server endpoint to dendrite

[matrixbot]

This issue was originally created by @twentybit at matrix-org/dendrite#1985.

Description:

I'm running dendrite on kubernetes, using an ingress controller. As ingress controllers can't host static content, I've had to spin up an NGINX pod to respond to the .well-known/matrix/server endpoint to enable federation.

This feels like something that should be hosted inside dendrite, as it's a mandatory API to enable federation?

Happy creating a PR if others think the above is sensible!

[matrixbot]

This comment was originally posted by @tulir at matrix-org/dendrite#1985 (comment).

It's not a mandatory API to enable federation, it's for redirecting federation traffic somewhere else. The only case where serving it from the homeserver is useful is if you're delegating to port 443 on the same IP (because the default federation port is 8448, while the .well-known port is 443).

That special case isn't rare though, so it might still make sense to have a config option for serving it.

[matrixbot]

This comment was originally posted by @kegsay at matrix-org/dendrite#1985 (comment).

Indeed, whilst .well-known isn't mandated, in practice you need to implement it to allow for flexibility. I'm happy to add an endpoint which serves this content. cc @neilalexander

This will also be useful for Complement - currently it doesn't use .well-known at all and when writing federation tests we always assumes reachability on :8448, but this makes it impossible to parallelise federation tests then (as the processes will attempt to bind to the same port). The current Dendrite image used for Complement doesn't serve .well-known at all.

[matrixbot]

This comment was originally posted by @neilalexander at matrix-org/dendrite#1985 (comment).

I think it's fine to add HTTP endpoints for these — in particular we'd want to serve .well-known/matrix/server on the federation router (in the federation API routing package) and serve .well-known/matrix/client on the client router (in the client API routing package).

Since Dendrite also has no means of knowing what the correct addresses should be to serve on these endpoints, we should probably also add some optional configuration options for if the URL differs in any way from the configured global server name.

[matrixbot]

This comment was originally posted by @twentybit at matrix-org/dendrite#1985 (comment).

@neilalexander - Sounds good.
The routers currently available to the clientapi and federationapi have PathPrefixes - _matrix/client, _matrix/federation, so I can't just reuse them for the well-known endpoints.
Should I just create a new mux.Router, and pass them through like the others, or create a new wellknownapi package?

[matrixbot]

This comment was originally posted by @neilalexander at matrix-org/dendrite#1985 (comment).

Good point about the path prefixes — I had forgotten about that. Probably best to make a new well-known mux.Router then and pass it through to the client API and federation API as needed. Making a new wellknownapi component will be much heavier than you think.

[matrixbot]

This comment was originally posted by @S7evinK at matrix-org/dendrite#1985 (comment).

Solved in matrix-org/dendrite#1988 i guess.

[matrixbot]

This comment was originally posted by @kegsay at matrix-org/dendrite#1985 (comment).

Yep.