Federated Auxiliary Service Providers

I’ve recently been learning about FASPs, and started playing around with making some prototypes. As it’s still a relatively new concept, and I’ve not been able to find much discussion on it, I thought I’d kick one off here. Obviously the amount of code for FASPs at the moment is small in both scope and deployment. So it’s probably more useful to focus on the potential of the concept, rather than its current state.

So for those who have looked into it:

  • What FASPs might you want one day to be available to your server to use?
  • Or what FASP features might you want to one day provide to other servers?

Or even just generally, I would love to hear people’s thoughts about the FASP concept overall.

1 Like

Is this any service, with a well-defined api, that is callable from the instance software? So the way hashtags work now could be a FASP as well? Or are we thinking more along the lines of .. alt-texting, translations, those kinds of things?

A similar concept already exists in ActivityPub: relays.

So far, no justification for a brand new protocol has been provided.

The current FASP work does seem to focused on addressing discovery, which has a large overlap with relays.

But my understanding is that is in theory the scope of services/capabilities can be much broader (e.g, Mastodon is working on one for content detection of spam/illegal material, and another for shared remote media storage).

So the way I was thinking about it (unclear if this is the way they intended) was considering what services or functionality I might want for my ActivityPub server that either:

  • benefit from not being siloed to my server (e.g, 3p integration, more data, or reduced cost)
  • or benefit from not being reliant on my ActivityPub software (e.g, more choice, or not as constrained by one teams bandwidth and roadmap priorities)

Oof that sounds exactly like the services that depend on the derogation of the ePrivacy directive, and like so, something we don’t want, Chat Control.

1 Like

Mastodon is working on one for content detection of spam/illegal material, and another for shared remote media storage

I think this is still not enough to justify a brand new protocol. ActivityPub is JSON and HTTP, after all, it can be used for anything.

With how Mastodon has been hesitant to implement pluggable federation filters and instead focuses on FASPs that mostly seem to be focused on 3rd party services interoperability, I’m not a fan of the whole idea. Something like Pleroma MRFs are, I think, a much better solution to a very similar problem, especially for content filtering/flagging. And they are local-first with the possibility of interacting with 3rd party services. Not the other way around.

1 Like

Now I have to explain myself a bit. I don’t like this vagueness phrasing since it pulls into the discussion: What kind of material. Now let’s get to the meat of the matter. Call things by their names. The ePrivacy derogation that makes this possible is made for the specific reason of CSAM, not any other kind of illegal material (or hate speech, however much we hate it).

I wanted to be clear about this one. I used to be employed at an inHope associate and even now I think that is something that needs to be clearly addressed and communicated to the users of instances that would use such a service.

All content will be scanned, flags will be raised on content that would be perfectly fine and acceptable in context for example. But yes, Fedi is not yet (and maybe luckily so) a place for baby-pictures.

So as a tip, please communicate your procedure to your users before enabling any of it for them.

Thanks.