MirrorHub/synapse
0
0
Fork 1
mirror of https://mau.dev/maunium/synapse.git synced 2024-06-10 22:58:53 +02:00
Code Issues Projects Releases Wiki Activity

Incorporate review

Browse source
This commit is contained in:
Brendan Abolivier 2020-02-18 17:20:03 +00:00
parent a0d2f9d089
commit 61b457e3ec
No known key found for this signature in database
GPG key ID: 1E015C145F1916CD
2 changed files with 17 additions and 21 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

22
docs/delegate.md
View file

@ -1,14 +1,13 @@
# Delegation
For a more flexible configuration, you can have `server_name`
resources (eg: `@user:example.com`) served by a different host and
port (eg: `synapse.example.com:443`).
Without configuring delegation, homeservers will expect the server
responsible for resources using e.g. `example.com` as their `server_name`
(e.g. `@user:example.com`) to be served at `example.com:8448`.
Without configuring delegation, the matrix federation will
expect to find your server via `example.com:8448`. The following methods
allow you retain a `server_name` of `example.com` so that your user IDs, room
aliases, etc continue to look like `*:example.com`, whilst having your
federation traffic routed to a different server (e.g. `synapse.example.com`).
Delegation is a Matrix feature allowing a homeserver admin to retain a
`server_name` of `example.com` so that your user IDs, room aliases, etc
continue to look like `*:example.com`, whilst having your federation
traffic routed to a different server and/or port (e.g. `synapse.example.com:443`).
## .well-known delegation
@ -38,11 +37,8 @@ should return:
Note, specifying a port is optional. If no port is specified, then it defaults
to 8448.
Most installations will not need to configure .well-known. However, it can be
useful in cases where the admin is hosting on behalf of someone else and
therefore cannot gain access to the necessary certificate. With .well-known,
federation servers will check for a valid TLS certificate for the delegated
hostname (in our example: `synapse.example.com`).
With .well-known, federation servers will check for a valid TLS certificate
for the delegated hostname (in our example: `synapse.example.com`).
## SRV DNS record delegation

16
docs/federate.md
View file

@ -17,13 +17,13 @@ on port 8448. The preferred way to do that is by using a reverse proxy,
see [reverse_proxy.md](<reverse_proxy.md>) for instructions on how to
correctly set one up.
In some cases you might not want Synapse to be running on the machine that
has the `server_name` as its public DNS hostname, or federation traffic
to use port than 8448 (e.g. you want to use `example.com` as your `server_name`
but want Synapse to be reachable on `synapse.example.com:443`). This can
be done using delegation, which allows an admin to dictate where federation
traffic should be sent, see [delegate.md](<delegate.md>) for instructions on
how to set this up.
In some cases you might not want to run Synapse on the machine that has
the `server_name` as its public DNS hostname, or you might want federation
traffic to use a different port than 8448. For example, you might want to
have your user names look like `@user:example.com`, but you want to run
Synapse on `synapse.example.com` on port 443. This can be done using
delegation, which allows an admin to control where federation traffic should
be sent. See [delegate.md](delegate.md) for instructions on how to set this up.
Once federation has been configured, you should be able to join a room over
federation. A good place to start is `#synapse:matrix.org` - a room for
@ -31,7 +31,7 @@ Synapse admins.
## Troubleshooting
You can use the [federation tester](<https://matrix.org/federationtester>)
You can use the [federation tester](https://matrix.org/federationtester)
to check if your homeserver is configured correctly. Alternatively try the
[JSON API used by the federation tester](https://matrix.org/federationtester/api/report?server_name=DOMAIN).
Note that you'll have to modify this URL to replace `DOMAIN` with your