From 61b457e3ec72ec005605b8569eae8b8e547101ee Mon Sep 17 00:00:00 2001 From: Brendan Abolivier Date: Tue, 18 Feb 2020 17:20:03 +0000 Subject: Incorporate review --- docs/delegate.md | 22 +++++++++------------- docs/federate.md | 16 ++++++++-------- 2 files changed, 17 insertions(+), 21 deletions(-) diff --git a/docs/delegate.md b/docs/delegate.md index 7b55827cec..57ae2c4c70 100644 --- a/docs/delegate.md +++ b/docs/delegate.md @@ -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 diff --git a/docs/federate.md b/docs/federate.md index 55f2a6d0ee..5fc839b58b 100644 --- a/docs/federate.md +++ b/docs/federate.md @@ -17,13 +17,13 @@ on port 8448. The preferred way to do that is by using a reverse proxy, see [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]() 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]() +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 -- cgit 1.4.1