mirror of
https://github.com/LemmyNet/lemmy-docs.git
synced 2024-11-21 11:51:11 +00:00
Merge pull request #66 from LemmyNet/federation-modes
Update docs for federation modes
This commit is contained in:
commit
96b1e118f3
1 changed files with 17 additions and 5 deletions
|
@ -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.
|
||||
|
|
Loading…
Reference in a new issue