git.squeep.com Git - akkoma/blob - docs/configuration/mrf.md

   1 # Message Rewrite Facility
   2 The Message Rewrite Facility (MRF) is a subsystem that is implemented as a series of hooks that allows the administrator to rewrite or discard messages.
   3
   4 Possible uses include:
   5
   6 * marking incoming messages with media from a given account or instance as sensitive
   7 * rejecting messages from a specific instance
   8 * rejecting reports (flags) from a specific instance
   9 * removing/unlisting messages from the public timelines
  10 * removing media from messages
  11 * sending only public messages to a specific instance
  12
  13 The MRF provides user-configurable policies.  The default policy is `NoOpPolicy`, which disables the MRF functionality.  Pleroma also includes an easy to use policy called `SimplePolicy` which maps messages matching certain pre-defined criterion to actions built into the policy module.
  14 It is possible to use multiple, active MRF policies at the same time.
  15
  16 ## Quarantine Instances
  17
  18 You have the ability to prevent from private / followers-only messages from federating with specific instances. Which means they will only get the public or unlisted messages from your instance.
  19
  20 If, for example, you're using `MIX_ENV=prod` aka using production mode, you would open your configuration file located in `config/prod.secret.exs` and edit or add the option under your `:instance` config object. Then you would specify the instance within quotes.
  21 ```
  22 config :pleroma, :instance,
  23   [...]
  24   quarantined_instances: ["instance.example", "other.example"]
  25 ```
  26
  27 ## Using `SimplePolicy`
  28
  29 `SimplePolicy` is capable of handling most common admin tasks.
  30
  31 To use `SimplePolicy`, you must enable it.  Do so by adding the following to your `:instance` config object, so that it looks like this:
  32
  33 ```
  34 config :pleroma, :instance,
  35   [...]
  36   rewrite_policy: Pleroma.Web.ActivityPub.MRF.SimplePolicy
  37 ```
  38
  39 Once `SimplePolicy` is enabled, you can configure various groups in the `:mrf_simple` config object.  These groups are:
  40
  41 * `media_removal`: Servers in this group will have media stripped from incoming messages.
  42 * `media_nsfw`: Servers in this group will have the #nsfw tag and sensitive setting injected into incoming messages which contain media.
  43 * `reject`: Servers in this group will have their messages rejected.
  44 * `federated_timeline_removal`: Servers in this group will have their messages unlisted from the public timelines by flipping the `to` and `cc` fields.
  45 * `report_removal`: Servers in this group will have their reports (flags) rejected.
  46
  47 Servers should be configured as lists.
  48
  49 ### Example
  50
  51 This example will enable `SimplePolicy`, block media from `illegalporn.biz`, mark media as NSFW from `porn.biz` and `porn.business`, reject messages from `spam.com`, remove messages from `spam.university` from the federated timeline and block reports (flags) from `whiny.whiner`:
  52
  53 ```
  54 config :pleroma, :instance,
  55   rewrite_policy: [Pleroma.Web.ActivityPub.MRF.SimplePolicy]
  56
  57 config :pleroma, :mrf_simple,
  58   media_removal: ["illegalporn.biz"],
  59   media_nsfw: ["porn.biz", "porn.business"],
  60   reject: ["spam.com"],
  61   federated_timeline_removal: ["spam.university"],
  62   report_removal: ["whiny.whiner"]
  63
  64 ```
  65
  66 ### Use with Care
  67
  68 The effects of MRF policies can be very drastic.  It is important to use this functionality carefully.  Always try to talk to an admin before writing an MRF policy concerning their instance.
  69
  70 ## Writing your own MRF Policy
  71
  72 As discussed above, the MRF system is a modular system that supports pluggable policies.  This means that an admin may write a custom MRF policy in Elixir or any other language that runs on the Erlang VM, by specifying the module name in the `rewrite_policy` config setting.
  73
  74 For example, here is a sample policy module which rewrites all messages to "new message content":
  75
  76 ```elixir
  77 defmodule Pleroma.Web.ActivityPub.MRF.RewritePolicy do
  78   @moduledoc "MRF policy which rewrites all Notes to have 'new message content'."
  79   @behaviour Pleroma.Web.ActivityPub.MRF
  80
  81   # Catch messages which contain Note objects with actual data to filter.
  82   # Capture the object as `object`, the message content as `content` and the
  83   # message itself as `message`.
  84   @impl true
  85   def filter(
  86         %{"type" => "Create", "object" => %{"type" => "Note", "content" => content} = object} =
  87           message
  88       )
  89       when is_binary(content) do
  90     # Subject / CW is stored as summary instead of `name` like other AS2 objects
  91     # because of Mastodon doing it that way.
  92     summary = object["summary"]
  93
  94     # Message edits go here.
  95     content = "new message content"
  96
  97     # Assemble the mutated object.
  98     object =
  99       object
 100       |> Map.put("content", content)
 101       |> Map.put("summary", summary)
 102
 103     # Assemble the mutated message.
 104     message = Map.put(message, "object", object)
 105     {:ok, message}
 106   end
 107
 108   # Let all other messages through without modifying them.
 109   @impl true
 110   def filter(message), do: {:ok, message}
 111
 112   @impl true
 113   def describe do
 114     mrf_sample = Pleroma.Config.get(:mrf_sample)
 115
 116     {:ok, %{mrf_sample: mrf_sample}}
 117   end
 118 end
 119 ```
 120
 121 If you save this file as `lib/pleroma/web/activity_pub/mrf/rewrite_policy.ex`, it will be included when you next rebuild Pleroma.  You can enable it in the configuration like so:
 122
 123 ```
 124 config :pleroma, :instance,
 125   rewrite_policy: [
 126     Pleroma.Web.ActivityPub.MRF.SimplePolicy,
 127     Pleroma.Web.ActivityPub.MRF.RewritePolicy
 128   ]
 129 ```
 130
 131 Please note that the Pleroma developers consider custom MRF policy modules to fall under the purview of the AGPL.  As such, you are obligated to release the sources to your custom MRF policy modules upon request.