Incorporate review

docs/delegate.md

 # 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
 

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](<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