description:"The instance's description, can be seen in nodeinfo and /api/v1/instance",
description:
"The instance's description. It can be seen in nodeinfo and `/api/v1/instance`",
suggestions:[
"Very cool instance"
]
...
...
@@ -770,7 +771,7 @@
key::cleanup_attachments,
type::boolean,
description:"""
"Enable to remove associated attachments when status is removed.
Enable to remove associated attachments when status is removed.
This will not affect duplicates and attachments without status.
Enabling this will increase load to database when deleting statuses on larger instances.
"""
...
...
@@ -838,7 +839,7 @@
%{
key::healthcheck,
type::boolean,
description:"If enabled, system data will be shown on /api/pleroma/healthcheck"
description:"If enabled, system data will be shown on `/api/pleroma/healthcheck`"
},
%{
key::remote_post_retention_days,
...
...
@@ -1296,14 +1297,14 @@
%{
key::media_removal,
type:{:list,:string},
description:"List of instances to remove medias from",
description:"List of instances to strip media attachments from",
suggestions:["example.com","*.example.com"]
},
%{
key::media_nsfw,
label:"Media NSFW",
type:{:list,:string},
description:"List of instances to put medias as NSFW (sensitive) from",
description:"List of instances to tag all media as NSFW (sensitive) from",
suggestions:["example.com","*.example.com"]
},
%{
...
...
@@ -1422,21 +1423,21 @@
key::reject,
type:[:string,:regex],
description:
"A list of patterns which result in message being rejected, each pattern can be a string or a regular expression.",
"A list of patterns which result in message being rejected. Each pattern can be a string or a regular expression.",
suggestions:["foo",~r/foo/iu]
},
%{
key::federated_timeline_removal,
type:[:string,:regex],
description:
"A list of patterns which result in message being removed from federated timelines (a.k.a unlisted), each pattern can be a string or a regular expression.",
"A list of patterns which result in message being removed from federated timelines (a.k.a unlisted). Each pattern can be a string or a regular expression.",
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.
Possible uses include:
...
...
@@ -10,7 +11,8 @@ Possible uses include:
* removing media from messages
* sending only public messages to a specific instance
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.
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.
It is possible to use multiple, active MRF policies at the same time.
## Quarantine Instances
...
...
@@ -18,7 +20,8 @@ It is possible to use multiple, active MRF policies at the same time.
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.
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.
Once `SimplePolicy` is enabled, you can configure various groups in the `:mrf_simple` config object. These groups are:
Once `SimplePolicy` is enabled, you can configure various groups in the `:mrf_simple` config object. These groups are:
*`media_removal`: Servers in this group will have media stripped from incoming messages.
*`media_nsfw`: Servers in this group will have the #nsfw tag and sensitive setting injected into incoming messages which contain media.
...
...
@@ -50,7 +53,7 @@ Servers should be configured as lists.
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`:
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.
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.
## Writing your own MRF Policy
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.
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.
For example, here is a sample policy module which rewrites all messages to "new message content":
...
...
@@ -118,7 +120,7 @@ end
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:
```
```elixir
config:pleroma,:instance,
rewrite_policy:[
Pleroma.Web.ActivityPub.MRF.SimplePolicy,
...
...
@@ -126,4 +128,4 @@ config :pleroma, :instance,
]
```
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.
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.
