Merge remote-tracking branch 'origin/master' into develop

changelog.d/4881.misc

@@ -0,0 +1 @@
+Update link to federation docs.

docs/federate.md

@@ -15,8 +15,8 @@ machine's public DNS hostname, and provide Synapse with a TLS certificate
 which is valid for your ``server_name``.
 
 Once you have completed the steps necessary to federate, you should be able to 
-join a room via federation. (A good place to start is ``#synapse:matrix.org``
-- a room for Synapse admins.)
+join a room via federation. (A good place to start is ``#synapse:matrix.org`` - a 
+room for Synapse admins.)
 
 
 ## Delegation
@@ -89,7 +89,6 @@ In our example, we would need to add this SRV record in the
 
      _matrix._tcp.example.com. 3600 IN SRV 10 5 443 synapse.example.com.
 
-
 Once done and set up, you can check the DNS record with ``dig -t srv
 _matrix._tcp.<server_name>``. In our example, we would expect this:
 
@@ -117,7 +116,6 @@ you invite them to. This can be caused by an incorrectly-configured reverse
 proxy: see [reverse_proxy.rst](<reverse_proxy.rst>) for instructions on how to correctly
 configure a reverse proxy.
 
-
 ## Running a Demo Federation of Synapses
 
 If you want to get up and running quickly with a trio of homeservers in a

docs/reverse_proxy.rst

@@ -18,7 +18,7 @@ servers do not necessarily need to connect to your server via the same server
 name or port. Indeed, clients will use port 443 by default, whereas servers
 default to port 8448. Where these are different, we refer to the 'client port'
 and the 'federation port'. See `Setting up federation
-<../README.rst#setting-up-federation>`_ for more details of the algorithm used for
+<federate.md>`_ for more details of the algorithm used for
 federation connections.
 
 Let's assume that we expect clients to connect to our server at