Add federation instructions. (#91)

* Add federation instructions.

* Fix line

* Fix another line

src/en/administration/configuration.md

@@ -12,3 +12,5 @@ If the Docker container is not used, manually create the database specified abov
 cd server
 ./db-init.sh
 ```
+
+**Federation is not set up by default.** You can add this [this federation block](https://github.com/lemmynet/lemmy/blob/main/config/config.hjson#L64) to your `lemmy.hjson`, and ask other servers to add you to their allowlist.

src/en/administration/federation_getting_started.md

@@ -1,5 +1,13 @@
 # Federation
 
+Lemmy has three types of federation:
+
+- Allowlist: Explicitly list instances to connect to.
+- BlockList: Explicitly list instances to not connect to. Federation is open to all other instances.
+- Open: Federate with all potential instances.
+
+**Federation is not set up by default.** You can add this [this federation block](https://github.com/lemmynet/lemmy/blob/main/config/config.hjson#L64) to your `lemmy.hjson`, and ask other servers to add you to their allowlist.
+
 Lemmy uses the ActivityPub protocol (a W3C standard) to enable federation between different servers (often called instances). This is very similar to the way email works. For example, if you use gmail.com, then you can not only send mails to other gmail.com users, but also to yahoo.com, yandex.ru and so on. Email uses the SMTP protocol to achieve this, so you can think of ActivityPub as "SMTP for social media". The amount of different actions possible on social media (post, comment, like, share, etc) means that ActivityPub is much more complicated than SMTP.
 
 As with email, ActivityPub federation happens only between servers. So if you are registered on `enterprise.lemmy.ml`, you only connect to the API of `enterprise.lemmy.ml`, while the server takes care of sending and receiving data from other instances (eg `voyager.lemmy.ml`). The great advantage of this approach is that the average user doesn't have to do anything to use federation. In fact if you are using Lemmy, you are likely already using it. One way to confirm is by going to a community or user profile. If you are on `enterprise.lemmy.ml` and you see a user like `@nutomic@voyager.lemmy.ml`, or a community like `!main@ds9.lemmy.ml`, then those are federated, meaning they use a different instance from yours.

src/en/contributing/federation_development.md

@@ -36,16 +36,7 @@ Note that federation is currently in alpha. **Only use it for testing**, not on
 
 Follow the normal installation instructions, either with [Ansible](../administration/install_ansible.md) or
 [manually](../administration/install_docker.md). Then replace the line `image: dessalines/lemmy:v0.x.x` in 
-`/lemmy/docker-compose.yml` with `image: dessalines/lemmy:federation`. Also add the following in
-`/lemmy/lemmy.hjson`:
-
-```
-    federation: {
-        enabled: true
-        tls_enabled: true,
-        allowed_instances: example.com,
-    }
-```
+`/lemmy/docker-compose.yml` with `image: dessalines/lemmy:federation`. Add and configure [this federation block](https://github.com/lemmynet/lemmy/blob/main/config/config.hjson#L64) to your `lemmy.hjson`.
 
 Afterwards, and whenever you want to update to the latest version, run these commands on the server:
 
@@ -66,4 +57,4 @@ actually identical to the post's creator, or that the user that removes a post i
 by the API code, and its the responsibility of each instance to check user permissions. This does not leave any attack
 vector, as a normal instance user cant do actions that violate the API rules. The only one who could do that is the
 admin (and the software deployed by the admin). But the admin can do anything on the instance, including send activities
-from other user accounts. So we wouldnt actually gain any security by checking mod permissions or similar.
+from other user accounts. So we wouldnt actually gain any security by checking mod permissions or similar.