lemmy/docs/src/contributing_federation_dev...

3.1 KiB

Federation Development

Running locally

Install the dependencies as described in Docker development. Then run the following

cd docker/federation
./start-local-instances.bash

The federation test sets up 5 instances:

Instance Username Location Notes
lemmy-alpha lemmy_alpha 127.0.0.1:8540 federated with all other instances
lemmy-beta lemmy_beta 127.0.0.1:8550 federated with all other instances
lemmy-gamma lemmy_gamma 127.0.0.1:8560 federated with all other instances
lemmy-delta lemmy_delta 127.0.0.1:8570 only allows federation with lemmy-beta
lemmy-epsilon lemmy_epsilon 127.0.0.1:8580 uses blocklist, has lemmy-alpha blocked

You can log into each using the instance name, and lemmy as the password, IE (lemmy_alpha, lemmy).

To start federation between instances, visit one of them and search for a user, community or post, like this. Note that the Lemmy backend runs on a different port than the frontend, so you have to increment the port number from the URL bar by one.

  • !main@lemmy-alpha:8541
  • http://lemmy-beta:8551/post/3
  • @lemmy-gamma@lemmy-gamma:8561

Firefox containers are a good way to test them interacting.

Running on a server

Note that federation is currently in alpha. Only use it for testing, not on any production server, and be aware that turning on federation may break your instance.

Follow the normal installation instructions, either with Ansible or manually. 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,
    }

Afterwards, and whenever you want to update to the latest version, run these commands on the server:

cd /lemmy/
sudo docker-compose pull
sudo docker-compose up -d

Security Model

  • HTTP signature verify: This ensures that activity really comes from the activity that it claims
  • check_is_apub_valid : Makes sure its in our allowed instances list
  • Lower level checks: To make sure that the user that creates/updates/removes a post is actually on the same instance as that post

For the last point, note that we are not checking whether the actor that sends the create activity for a post is actually identical to the post's creator, or that the user that removes a post is a mod/admin. These things are checked 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.