Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update docs for federation modes #66

Merged
merged 1 commit into from Apr 27, 2021
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
22 changes: 17 additions & 5 deletions src/en/federation/administration.md
Expand Up @@ -15,14 +15,26 @@ Federation does not start automatically, but needs to be triggered manually thro

For an overview of how federation in Lemmy works on a technical level, check out our [Federation Overview](contributing_federation_overview.md).

## Instance allowlist and blocklist
## Federation Modes

The federation section of Lemmy's config has two variables `allowed_instances` and `blocked_instances`. These control which other instances Lemmy will federate with. Both settings take a comma separated list of domains, eg `lemmy.ml,example.com`. You can either change those settings via `/admin`, or directly on the server filesystem.
Through the combination of federation config options, there are a couple different federation modes, differing in their restrictiveness. For now we don't recommend to use open federation, because moderation tools are lacking and there might be security problems in the federation code. Open federation should be fine for test instances and smaller instances, but bigger instances should prefer to use a more closed federation.

It is important to note that these settings only affect sending and receiving of data between instances. If allow federation with a certain instance, and then remove it from the allowlist, this will not affect previously federated data. These communities, users, posts and comments will still be shown. They will just not be updated anymore. And even if an instance is blocked, it can still fetch and display public data from your instance.

By default, both `allowed_instances` and `blocked_instances` values are empty, which means that Lemmy will federate with every compatible instance. We do not recommend this, because the moderation tools are not yet ready to deal with malicious instances.
### Using allowlist, strict_allowlist = true

What we do recommend is putting a list of trusted instances into `allowed_instances`, and only federating with those. Note that both sides need to add each other to their `allowed_instances` to allow two-way federation.
The most strict mode. Lemmy will only federate with instances from the allowlist, and block everything else. This includes all posts, comments, votes and private messages, you will only see them if the author is on an allowed instance. This means that remote communities or threads can be incomplete, as your instance will block any posts or comments whose author is not on an allowed instance.

Alternatively you can also use blocklist based federation. In this case, add the domains of instances you do *not* want to federate with. You can only set one of `allowed_instances` and `blocked_instances`, as setting both doesn't make sense.
The blocklist is ignored in this mode.

### Using allowlist, strict_allowlist = false

This mode is a bit more open than the one above. For local communities, the behaviour is identical, only users from allowed instances can post, comment or vote. The difference is with remote communities. The allowlist doesn't apply to them, so you will see all posts, comments and votes in remote communities (unless the author's instance is blocked). Private messages can be sent by any remote user that isn't blocked.

If a blocklist is set, all communication with the blocked instances will be prevented, no matter in which context.

### Using only blocklist

If no allowlist is specified, Lemmy will federate with any instance. This is the most open mode, and potentially the most risky, as someone could create a malicious instance, and immediately send spam or other problematic content to your instance. You can use the blocklist to prevent federation with such instances one by one.

`strict_allowlist` is ignored in this case.