jq -s add ${pkgs.akkoma-frontends.akkoma-fe}/static/config.json ${config} \
      >$out/static/config.json
  '';
}
```

## Federation policies {#modules-services-akkoma-federation-policies}

Akkoma comes with a number of modules to police federation with other ActivityPub instances.
The most valuable for typical users is the
[`:mrf_simple`](https://docs.akkoma.dev/stable/configuration/cheatsheet/#mrf_simple) module
which allows limiting federation based on instance hostnames.

This configuration snippet provides an example on how these can be used. Choosing an adequate
federation policy is not trivial and entails finding a balance between connectivity to the rest
of the fediverse and providing a pleasant experience to the users of an instance.


```nix
{
  services.akkoma.config.":pleroma" = with (pkgs.formats.elixirConf { }).lib; {
    ":mrf".policies = map mkRaw [
      "Pleroma.Web.ActivityPub.MRF.SimplePolicy"
    ];

    ":mrf_simple" = {
      # Tag all media as sensitive
      media_nsfw = mkMap {
        "nsfw.weird.kinky" = "Untagged NSFW content";
      };

      # Reject all activities except deletes
      reject = mkMap {
        "kiwifarms.cc" = "Persistent harassment of users, no moderation";
      };

      # Force posts to be visible by followers only
      followers_only = mkMap {
        "beta.birdsite.live" = "Avoid polluting timelines with Twitter posts";
      };
    };
  };
}
```

## Upload filters {#modules-services-akkoma-upload-filters}

This example strips GPS and location metadata from uploads, deduplicates them and anonymises the
the file name.

```nix
{
  services.akkoma.config.":pleroma"."Pleroma.Upload".filters =
    map (pkgs.formats.elixirConf { }).lib.mkRaw [
      "Pleroma.Upload.Filter.Exiftool"
      "Pleroma.Upload.Filter.Dedupe"
      "Pleroma.Upload.Filter.AnonymizeFilename"
    ];
}
```

## Migration from Pleroma {#modules-services-akkoma-migration-pleroma}

Pleroma instances can be migrated to Akkoma either by copying the database and upload data or by
pointing Akkoma to the existing data. The necessary database migrations are run automatically
during startup of the service.

The configuration has to be copy‐edited manually.

Depending on the size of the database, the initial migration may take a long time and exceed the
startup timeout of the system manager. To work around this issue one may adjust the startup timeout
{option}`systemd.services.akkoma.serviceConfig.TimeoutStartSec` or simply run the migrations
manually:

```ShellSession
pleroma_ctl migrate
```

### Copying data {#modules-services-akkoma-migration-pleroma-copy}

Copying the Pleroma data instead of re‐using it in place may permit easier reversion to Pleroma,
but allows the two data sets to diverge.

First disable Pleroma and then copy its database and upload data:

```ShellSession
# Create a copy of the database