Skip to content

MRF / Dropping of incoming/outgoing messages based on allow-list

Agate requested to merge 853-allow-listing-drop into develop

See #853 (closed)

This MR implements the actual filtering of content based on allow-list. I've proceed to a rather important refactor of the internal logic for blocking/discarding content. This change mimics Pleroma's Message Rewrite Facility (MRF) which is a flexible and pluggable system to automate moderation of incoming and outgoing content when built-in options aren't granular or powerful enough.

Instance and account blocking (which was released in 0.19) was reimplemented on top of this, and for consistency we're also checking fetched object (e.g libraries fetched through the UI) against the MRF.

When we talk about allow-listing, we're in fact referring to:

  • Drop processing of inbox activities when allow-list is enabled and the domain of the activity actor, object or id isn't on the allow-list
  • Drop delivery of outbox activities when allow-list is enabled and the activity recipient domain isn't on the allow-list
  • Prevent the fetching of objects from non-allowed servers

All of these are implemented in this MR.

Verification of inbox activities against the allow-list is entirely done through a MRF policy. However, for the outbox part, I wasn't comfortable with the performance impact of mutating the list of recipients through MRF, so it's implemented by hand, in the delivery logic.

Fetching of remote objects is also going trough the MRF, meaning our allow-list applies here, as well as any other MRF policy.


This MR also fix some logging configuration issues (basically, nothing was logged to stdout xD), which was really annoying when writing MRF policies ;)

Testing/debugging MRF

This MR includes a python mrf_check command that you can use to check a given message against the MRF (or a subset of rules). This is especially useful when writing a new MRF policy or to debug message delivery.

Usage is documented at

Third-party MRF via plugins

I've added the minimal settings to support the inclusion of third-party MRF via a basic plugin system. Plugins are regular django applications, living in $FUNKWHALE_PLUGINS_PATH (/srv/funkwhale/plugins by default). To have Funkwhale load a plugin, just provide it's name via FUNKWHALE_PLUGINS=myplugin,anotherplugin.

Plugin creation MRF writing is documented at Usage is documented at

I've added a license warning, as Pleroma did:

Please note that the Funkwhale 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.

I think it's a good thing, but if you see any issue with that, we can discuss it :)

Edited by Agate

Merge request reports