Federation "Approval First" Mode

[vitunvuohi]

Pitch

This pitch is for a federation mode between allowlist and full promiscuous federation which would allow instance admins to review new instance peers the same way they review trending posts, tags, or account approvals. The instance could be silenced or suspended on first contact until such a time as the admin "approves"/removes the block.

Admins could opt to get a daily email and then enter into the admin screen and see a short preview of every new instance with an interface similar to the trending posts one and approve/deny in bulk.

Motivation

As the federation grows and our instances grow, the list of bad actor instances grows with it. While we can cut down on spam with account approvals and now manage blocks through the api (thank you!), these are still somewhat limiting when dealing with bad faith instances, and many times have admins scrambling in a reactive way to deal with incidents that come from other servers.

I believe a lot of smaller instances who may not have the time or resources to devote to playing whack-a-mole with spam or harassment instances an easier time managing the flood of new peers popping up.

[Packbat]

As an instance moderator, I love this idea.

Also, an interesting implementation detail: what data can an instance effectively retrieve about a new instance to help with deciding whether to accept the connection?

Thinking about this particularly with regard to instance rules, which sometimes:

• appear on the about/more page
• appear in a special section of the about/more page
• appear in the terms of service
• appear in an external page that is linked from a standard informational page
• appear in the profile of an official instance announcements account
• appear in an external page linked from the profile of an official instance announcements account...

Making this information easily accessible in the same UI used for approving instances would be amazing, but not if it fails for a substantial portion of instances.

[manedfolf]

I support this. It sounds like a great compromise between open federation and whitelisted federation, especially given that end users wouldn't even be directly affected by it.

Without knowing how many instances get spun up, it might also be worth having an auto-approve timeout by default so that things don't get stuck in limbo.

@Packbat it would be handy to have that info, and Mastodon instances would be able to do that easily, but other fediverse software is a crapshoot, and I have a feeling a lot of single user instances might not even bother - so it would not be a 100% solid metric to base decisions off of.

[VyrCossont]

I really really want this. The feature becomes even more useful given the rapid growth of the Fediverse, the constant recurrence of the same bad actors on #FediBlock as new admins learn the hard way that some instances are harassment vectors, and specifically the deployment of tools like activitypub-proxy and Mastinator that are purpose-built for bypassing instance blocks, given the current allow-federation-by-default policy.

Plumbing-wise, we'd need to queue incoming AP messages from instances not explictly approved or rejected, and only process or drop them once an admin makes the call. Not sure whether Redis or PG would be the appropriate storage location, but they may need be persisted for hours to days, and should survive a Redis reboot or loss. They'd need to be indexed by instance and store the AP message and probably an arrival time, so that admins reviewing instances can see when an instance became visible to their own.

I'd argue that this should be the same with outgoing communication: sending messages to other instances should be queued until approval or rejection of that instance.

This needs admin API for listing unknown/pending instances attempting to federate, maybe api/v1/…:

• domain_pending: list instances
  • instance domain
  • first seen
  • last seen
  • count of pending AP messages, maybe also a breakdown of count by actor
  • instance metadata from remote instance's instance APIs
    • software
    • version
    • rules
    • user count
    • activity
• domain_allows: approve domains, already exists
• domain_block: reject domains, already exists

These APIs should also have web UI but shouldn't need a CLI as domain blocks and allows are not exposed by the CLI either.

It'd be useful to advise users of greylisted outbound instances by showing some sort of warning in the web UI when they @ someone on an unknown instance, but this would need a new client-facing API, and other activities such as favs or boosts don't really have anywhere to add that UI; likewise third-party clients would not be aware of what's going on without support for that warning API.

What am I missing?

Previous issues related to this: #20627, #4296 (a weaker version).

[mattieb]

It'd be useful to advise users of greylisted outbound instances by showing some sort of warning in the web UI when they @ someone on an unknown instance, but this would need a new client-facing API, and other activities such as favs or boosts don't really have anywhere to add that UI; likewise third-party clients would not be aware of what's going on without support for that warning API.

Could we punt (on outbound only) and just return an error to the sending client, and not queue that message?

[VyrCossont]

Could we punt (on outbound only) and just return an error to the sending client, and not queue that message?

Oh, sure, and we should.

I was envisioning the warning API as something that'd trigger if you tried to @ someone on a greylisted remote instance before actually sending the message. But I'm not sure if we'd even have a local copy of their account yet, because greylist, so it'd only happen on responding to a thread or if someone typed out their fully qualified username. The desired user experience would be that you don't type out a message and then lose it to a send error with no warning, since Mastodon doesn't have drafts to put failed messages into.

[ryliejamesthomas]

I'd also find this really useful. Would've been great when all the massive instances started appearing after the big Twitter migration, and would be great now that someone's seemingly launching a new scraper every other day (though secure mode helps there, at least). Playing whack-a-mole is becoming too much work, and the allow-list option as it currently exists is far too restrictive. An approval-first mode when new instances are quarantined and listed in the admin UI, so they can be investigated when time's available would be ideal.

RE: Packbat's post, the most useful information to include for how I manage things would be a link to the instance. Showing rules would help weed out a few places, but lots of instances just use some boilerplate and don't follow it anyway. I imagine I'll have to manually visit 90% of servers anyway. Being able to put Soapbox instances straight in the bin'd be handy~

There also needs to be a method to move an instance from block-list based federation to approval-based, so that we wouldn't be starting from scratch again. Blocked instances stay blocked, at least. Existing federated instances could be ranked by number of connections/interactions, so we can approve the most necessary ones first—something like that.

---

I thought we had a longer thread about this years ago (not #4296), but I guess it's just something that's come up in other contexts a lot before.

[rscmbbng]

To add to this conversation:

In Peertube, a similar mechanism exists where instances can follow one another. When they do, remote content from the followed instance becomes visible on the local one. However, it is possible to require manual approval of follow requests allowing the admin team to vet the instance before the content propagates. Instances where this doesn't happen are notorious for hosting really random low-quality content or even malicious content such as conspiracy videos.

I've suggested a similar feature for the Hometown fork: hometown-fork#1237 calling it cautiously optimistic federation, based on https://decentpatterns.xyz/library/cautious-optimism/

What would be useful is to have a page with where "connection requests" are collected. For each there would be not just a hostname (which is the case in Peertube) but short summary of the instance which includes the software type, banner images, description and policy for example.

Finally, there is a clear tension here between content discovery this proposal. I'm not sure how this can be resolved elegantly at the moment. But it could already happen in the way of receiving a notification that a new link to another server has been established, as it gives the possibility to check it out. Currently servers just connect and bad actors can fly under the radar for a long time.

[ThisIsMissEm]

To implement this properly, you'd want to merge domain_blocks and domain_allows tables into an domain_federation_policies table, which would be a accept / reject / filter policy, along with filters that are actually granular.

I'm working on a article documenting how this would work, and may be working on a fork of the Mastodon code to implement exactly this.