[feature] Message Rewrite Facility

[w3bb]

Is your feature request related to a problem ?

One of the killer features of Pleroma is the Message Rewrite Facility. It allows you to make policies that can dynamically modify activities before they reach the inbox/outbox.

Describe the solution you'd like.

Goto could benefit from the same feature, especially as it's in alpha where some federation options are missing.

Describe alternatives you've considered.

While policies could be implemented manually by Goto, some specialised policies would not work as a part of upstream. Entire classes of feature requests like #9 would be pretty much solved if we went the MRF route.

Additional context.

There are some approaches for this:

yaegi

Yaegi has some cool interop features, which allows resources to be passed between the interpreter and the host. Goto could expose a package, say github.com/superseriousbusiness/gotosocial/mrf

 package mycoolmrfpolicy

 import (
    "github.com/superseriousbusiness/gotosocial/mrf"
     "strings"
 )

 func init() {
     mrf.Register("My Cool MRF Policy", rewrite)
 }

 func rewrite(activity mrf.Activity) mrf.Activity {
      if strings.Contains(activity.Body, "among us") {
           activity.Rejected = true
      }

      return activity
 }

The details here would probably vary. Does it register an interface? Is the mrf.Activity object just the raw object or an intermediate representation?

An upside to this implementation is that bundled policies with Goto's source code could be compiled to native Go and get better performance, so people who have more complicated policies can use their own build of Goto to get a performance boost.

lua

Lua might also be an option, but it would complicate the build process by introducing C (there are go-native implementations, but at that point it would make more sense to use yaegi.) There also isn't Go's standard library, so a lot of manual work to make something usable would have to be done. The upside is that with LuaJIT it would be very fast.

[w3bb]

(Also, I'm making this issue because I'm considering implementing it, wondering what you all might think.)

[igalic]

re Lua: there's https://github.com/Shopify/go-lua that's a reimplementation. so no LuaJIT

[tsmethurst]

I don't really understand the benefit of what you're proposing.

make policies that can dynamically modify activities before they reach the inbox/outbox

Can you give an example of when/why you would want to do this? I can understand why muting certain words exists (so people can filter out sex/violence/slurs etc from their home timeline), but actually rewriting the content of the messages as they come in seems kinda silly (and misleading).

[igalic]

for example: some people follow Kink, or food related instances, which post their interest (and pics) without CW.

Now, you don't wanna mute these instances, but you could just auto-cw their stuff, or hide their images default, so that if some of your users are following these instances, you don't get it all splat onto your federated timeline.

and you can build special UI for each such use-case, or, you can expose your API to a smol scripting language, and let admins build (and share) their own rules

[w3bb]

I don't really understand the benefit of what you're proposing.

make policies that can dynamically modify activities before they reach the inbox/outbox

Can you give an example of when/why you would want to do this? I can understand why muting certain words exists (so people can filter out sex/violence/slurs etc from their home timeline), but actually rewriting the content of the messages as they come in seems kinda silly (and misleading).

I did a poor job of giving examples. The Pleroma MRF page has some examples, but I'll give some more.

MRF polices are much more flexible in what you can do with filters. For example, you could count the occurances of a word, or modify the word to be censored le ts. It opens the door to more specialsed moderation strategies and also enables cool stuff. For example, you could have an MRF that sends a DM from an account to the user to be civil if certain criteria are met.

That's something I failed to mention, depending on what's exposed you can use side effects. Perhaps you might be running an external server that keeps track of how many times a user has broken the rules and automatically denies posts until a moderator has approved their account. Or an MRF policy for a Report activity could push out the report to a webhook URL.

Pleroma has had this for a very long time, and in practice it works very well. Pleroma uses MRF policies internally for things like instance blocks. Perhaps things like modifying the activity could be seen as misleading, however Pleroma also (optionally) exposes a list of MRF policies in nodeinfo so people can see what they have enabled. Goto could take advantage of that facility to communicate what policies it has enabled.

[igalic]

I think a problem with this idea is that it's taken from a place where bad ideas were paramount and bad actors reigned free for the longest time.

i don't know if Akkoma allows the same bad behaviour we've seen from Pleroma instances, such as, accounting of users / instances that blocked your users, rather than handle reports…

[w3bb]

accounting of users / instances that blocked your users

The latter has nothing to do with Pleroma and Pleroma is not capable of enumerating that. The prior could be avoided by not passing Block activities to MRF policies. I think the positives far outweigh the benefits, especially since there are measures to prevent abuse.

[f0x52]

This request still seems to come from such a place. The only reasonable subset of functionality I see is automatic adding of content warnings and media sensitivity. maybe keywords based but I think just setting it per user/instance is already effective enough.

Filtering out the slurs doesn't make the people you buddy-buddy with any better...

[tsmethurst]

Hmm, I don't think this is something we'll be implementing (just spoke to some of the other devs about it too).

Admins can already defed from instances and suspend users, and users can already unfollow/block/report, and will be able to filter/mute soon as well. Adding extra bells and whistles like MRF feels like sugarcoating and implicitly condoning bad behavior, when there are already pretty decent ways of dealing with it directly -- and in future we'll also have allowlist federation too.

Besides, on a technical level it also adds quite some dependencies + maintenance (a whole domain specific language basically!). It feels like putting on very thick and fancy gloves to handle toxic waste, when it's more reasonable to not be around toxic waste in the first place (if that analogy makes sense).

[Seirdy]

I agree that Pleroma instances tended to use the MRF in ways that enabled toxicity. However, it can really be used for just about anything. Some use-cases for MRF that don't revolve around getting closer to toxicity:

• AntiFollowBotPolicy: does what it sounds like.
• Rewriting links. Twitter links can become Nitter links, for instance.
• Force-appending "re: " to a CW when replying.
• Controlling permitted markup.
• NoPlaceholderTextPolicy: stripping placeholder text from image posts (".").
• HellthreadPolicy: blocks messages with too many mentions.
• NoEmptyPolicy: blocks empty statuses, or statuses with just mentions.
• Patching over incompatibilities between implementations.

I agree that a full MRF would be a bit much, but some equivalents to the most popular MRFs would be nice:

• Simple spam mitigations (AFP, HP, NPTP, NEP) can complement rather than replace active moderation.
• Automatic link-rewrites will probably be a well-received improvement: many instances also host e.g. Nitter, Invidious, Libreddit, etc. on different subdomains.
• A way to configure specific circumstances under which to expire old content could also help people running low on disk space (existing MRFs existed to expire/reject local and federated events beyond a certain age).