Post by @lrhodes@merveilles.town

I see benefits and potential detriments to this: https://bonfirenetworks.org/posts/building-shared-infrastructure-for-the-fediverse/

Obviously, the ability to plug into services that take some of the load off of home servers could help fediverse admins avoid some common problems.

But at the same time, we're talking about interjecting third parties into relationships that have previously been much more direct, and it's reasonable to be concerned about what that might entail. I hope admins will go slow and think through the possibilities.

Building shared infrastructure for the Fediverse

Bonfire is working with Mastodon to make remote media storage and automated content detection interoperable across the fediverse.

5 Replies

2 Boosts

⁂ L. Rhodes

@lrhodes@merveilles.town 4 hr. ago

One advantage to this structure is that it's much more optional than similar services on ATproto, so (at least in principle) instances can simply decline to use them if they have concerns. The risk to be aware of is FASP services becoming the de facto standard, such that it becomes difficult to operate a server without them, either because expected features become virtually impossible without them, or because instances won't (or can't) federate with instances that don't use some particular FASP.

⁂ L. Rhodes

@lrhodes@merveilles.town 3 hr. ago

What I would love to see is a big, serious conversation about what sort of limits and best practices should be brought to the deployment of FASPs. There needs to be serious consideration of the trade-offs of adding third parties to not just the technical, but also the social functions of the fediverse. And hopefully we can achieve some clarity about which trade-offs are worth it, and which are not, in advance of anyone getting burned by unwary adoption.

⁂ L. Rhodes

@lrhodes@merveilles.town 3 hr. ago

To be clear, I'm talking about a conversation beyond the ones that I'm sure are taking place within FASP development at Mastodon and its partners. Specifically, it's a conversation that needs to include admins and fediverse account-holders, since they're the ones who will ultimately be affected by the deployment of these additions.

⁂ L. Rhodes

@lrhodes@merveilles.town 3 hr. ago

Here's an example: I'm generally wary of talk about "data sovereignty," but if that's something you're interested in, FASPs create a potential complication. Choosing a host instance in your home region only matters if they're not routing all data through a moderation FASP in some other country operating under another legal paradigm. At the very least, we should want clear, automated signals when an instance connects with an outside FASP so we can make informed decisions about account hosting.

1+ more replies

Julian Fietkau

@julian@fietkau.social 3 hr. ago

@lrhodes Going by what I hear most often from server admins, the two things where they're most looking forward to FASP functionality is media hosting (shared caches instead of everything being duplicated per instance) and moderation (from block lists to spam detection, less so about individual moderation actions).

The poster child of FASP is keyword search, but I don't know how obvious the improvements there are going to be.

Have you read @renchap's blog post from 2023? https://renchap.com/blog/post/evolving_mastodon_trust_and_safety/

Renaud Chaput

Evolving Mastodon’s Trust & Safety Features • Renaud Chaput

Here are my personal thoughts about how we could handle Trust & Safety features in Mastodon software. This is based on my own experience in the field, my current knowledge of the source code and architecture, as well as my experience managing infrastructure for mastodon.social & mastodon.online since December 2022. Context Managing a Mastodon instance is hard work, with the most effort going to moderation and abuse, and not technical operations as one might expect. This includes:

2+ more replies