Islands: An Opt-In Federated Network
What if we were all just a bunch of allowlist-only servers talking to each other, in the process creating an entirely new network? A proposal.
Background
Safety on the fediverse is a difficult problem to solve, especially since it's a reflection of the wider internet: everything can link to any other thing. By default, there are few restrictions.
The problem is not aided when you have an issue of contrasting audiences who want fundamentally different things out of social media with contrasting expectations, smashing into each other.
There are other reasons to be nervous: AI mining farms wanting to pull in content to train chatbots, while Mastodon will still not allow us to block the goddamned RSS feeds. Reply control is also distant in the future of Mastodon, though it is already being worked on in GTS.
There are also many other ideas in this space that remain to be implemented and without placing blame about how long it takes to do things, it still might be longer than people are willing to wait.
Then there is the racist harassment on “the Mastodon” (which is how a lot of people think of the platform in tandem with the Mastodon.social-centric view of the fedi) has become what feels like a largely unwinnable situation under the current model, while moderation and safety tools remain lacking, and while moderation itself has become inherently decentralized, and everything is localized around the “fediverse that mastodon.social built.”
Most of our tools revolve around blocklists, since assholes do tend to cluster together. But it doesn't rule out everything. There are vanilla open registration servers out there, and nazi bigots can easily join those. New servers can pop up, under the radar, and we're always vulnerable since we inherently accept federation from all new servers by default. Even if we know of the server, not everyone blocks them or updates regularly. Even if we block their server, they can just join another open registration server with a new account.
In short, preventing this from happening entirely is impossible with our current tooling, particularly due to open-registration servers and open federation.
In addition to these vulnerabilities, there aren't server-level filters to flag or block certain phrases that would make moderation or even recognition of problem posts easier, which means someone has to receive the abuse first, report it, and then the user can be removed and banned from the server.
Though not from every server. Moderation decisions are not shared like that. So they can continue to spread abuse, with each server having to encounter them separately, and the network is so porous they can always come back later, in another form.
So the current scenario is to wait for abuse to happen, and hope to get a report. Moderators watch for bad actors in threads and from reports and by sharing details among their councils, but they can't see everything. The tools don't make it easy, because the tools for doing that don't exist.
The ultimate issue, the elephant in the room, is that the standard and “approved” form of federation as dictated on stone tablets by Old Man Mastodon, is an open federation model that depends on denylists, which reduces the scope of the problem, but the underlying problem remains.
The problem is that we can't speak for—or influence—the entire network. I can't control what happens on a random server, and I can't control your experience on a server that federates with it. I can only control what happens on my server.
But what if we could do more? What if we could take responsibility for the entire network because every member of the network has opted-in and agreed to abide by certain rules?
No one has ever really explored what a network of allowlist servers at scale might look like, but it provides many advantages over the current model, as well as some unique challenges.
It's fairly easy to see why this idea hasn't been widely explored, and why open federation is so popular. If you federate with everyone by default, you don't have to spend a lot of time figuring out “what are the servers I can talk to and how do I know what they are?” You can import a blocklist and largely avoid the worst of the internet, and federate with all but a small subset of servers.
By contrast, it's not as friendly to start up in limited federation, because there are no existing allowlists, and without an allowlist, you're just a private server that doesn't federate. And where to get a good allowlist? How are those made? Who decides?
In particular, just creating a good allowlist is itself a problem, although db0 suggests one method using Fediseer. Another method involves looking at your current list of followers and who you follow and starting an allowlist which is an intersection based on that. (@burnoutqueen@tech.lgbt made a script for this.) This script has the added advantage of allowing you to migrate to that server from an open federation server without losing any connections.
But there's not really much of a culture for this. There's not much discussion on how this might work at scale, and how this could actually be a workable model, and how networks of allowlisted servers could form.
And that's the issue: if you're going to create a network of allowlisted servers, then you need to publish a membership list and every island on the list needs to federate with the others, or you don't have a contiguous network.
Exactly how you technically create an allowlist for your network and update it is beyond the scope of this document, all that matters is that you create one and have it posted somewhere accessible so that others can review it or pull it and decide if they want to join your network or not.
Starting from Scratch
Rather than try to figure out which servers should be part of “the official allowlist”, let's do something else.
Let's start from scratch. Let's just declare that we're creating a new kind of server, and a new kind of network and if you want to join it, you don't migrate your account from somewhere else, you're going to be creating a whole new follower list, and a whole new social graph, in a whole new network.
Let's emphasize smaller servers, let's make it easier for a person or three to create their own Island, and decide what networks they want to join.
You're going to be joining an Island, and that Island is going to be part of a larger network of islands, or archipelago.
You're On an Island
What is an Island, in a social media sense?
It is its own standalone community, a social media server like GoToSocial, Mastodon, or similar. Your island is a community in its own right. Ideally it also supports local-only posting, allowing for private conversations among people on the same island, while also allowing for broadcasting to the wider “archipelago” or island network.
What are the requirements?
These should be the bare minimum:
- Anything but an open signup server: Signups should be reviewed, or closed registration/invite-only. This should prevent someone creating a throwaway abuse account or scripting a spam bot attack via this model.
- Server is Limited Federation: This means the server works in allowlist mode, rather than denylist, only federating with servers specifically on its allowlist.
- Ironclad commitment to user safety and accountability, a commitment to fair speech, and at least the first principle of the Mastodon Server Covenant.
In addition, there are a few opinionated recommendations:
- Have some server rules, and enforce them.
- Authorized/Secure Fetch, or the equivalent.
- Servers should be small, ideally 50 people or less to be manageable and easily moderated. (Seize the means of posting, make your own!)
- A Safe Harbor for those who are looking for a better network.
- All Admins/Moderators within a given network should have an open communication channel, even if it's simply a long DM thread, to coordinate moderation of individual users across the network.
Then there are some specific anti-recommendations:
There is no required server software, there can be GoToSocial islands, Mastodon islands, Akkoma islands, Misskey islands, etc. The only real hard requirement is that they have to support allowlist or limited federation.
There is no requirement on how “scrapeable” the posts from a given Island server network should be (ie., RSS or unauthenticated public access). This can be a requirement for a particular network but need not be a requirement of all networks.
Joining an Island Network or “Archipelago”
In these early stages, we will need to develop and maintain tools for networks, and support the idea of multiple allowlists, or multiple island networks.
Joining a given network is a consent-first model, requiring mutual opt-in. If everyone in the network is pulling from the same shared allowlist and federating with all the servers on the network, new servers can quickly be added to the network and start federating with each other.
Understand, since all the servers in the network are allowlisted, connections must be mutual in order for you to communicate with another Island. This means that if 'SomeServer.com' wants to communicate with you, you have to add 'SomeServer.com' to your allowlist. Meanwhile, 'SomeServer.com' also has to add your server to their allowlist, making it a completely reciprocal (and consentual) relationship.
The key to making this system work is published lists of members of a given network, that can be pulled down by an api or other means, realtime, and imported manually as a list (or else via subscription to an allowlist feed, coming in a future release of GoToSocial, for instance)
In addition to the official current members of a network, you'll need to account for provisional membership as well as inactive or suspended membership to a network.
Allowlists (Core)
The core lists themselves should be kept as simple as possible. We're not looking for gradations here, with varying degrees of allowing-ness, we just need a simple yes/no for allowlisting. It's boolean. Are they on the list or not?
That means an allowlist is just a csv file with line separators.
Example:oasis-network.csv
cool-server.example
my-other-cool-server.example
wingdings.ko.example
...
Easily imported, easily dumped out at any given URL, and thus easily subscribed to, imported, or just copy and pasted. It doesn't really matter how the allowlist gets regularly updated, even if it's manual, only that it does, since no one can participate in the entire network until the entire network adds them back. Admins of servers in a network should always be ready to manage syncing server federation across the network, and updating list membership from provisional to core.
So, okay, let's say we've got an existing network, with five servers on it.
What about when server number six comes along? How does it join that network? How does that work?
Provisional Membership
This is where provisional lists come in. By definition, having a provisional membership to a network is like saying this:
“Here's a server that wants to join the network and some members of the network might already be federating with them, but not all.”
There may be many reasons for this. Maybe one of the servers has hesitations about letting that server join the wider network. Maybe one of the admins of the server with federation privileges isn't available for a few days. Or perhaps a given network or a given island has instituted a policy that there's a 1 month waiting period on the Provisional List before being moved to the Official List.
In this way, servers joining a given network can subscribe to the “core” or official (more trusted) list of servers. Then, if they want, they can go ahead and allowlist any or all of the current provisional servers in advance of making it to the official list.
For ease of bookkeeping, though, and avoiding unnecessary process, I'd suggest that a server is on a provisional list until every server in the network is federating with them, however long that takes, and they are federating with the rest of the network in return. It must be unanimous. Once it is, that server is now an official part of the network.
In the event there is some sort of irrevocable breach, where a given server in a network doesn't want to federate with another server at all, by definition that server drops back to 'provisional' status.
Inactive and Suspended Lists
You will probably also want to list servers that might once have been provisional or even official members of the network, but the admin has gone AWOL or the server is no longer responding to requests for new members to the network.
And having a Suspended list is good, for historicity, so other members of the network can decide if they want to remain federated or not. Like a list of retractions.
FAQ
Here's a few answers to what are likely to be common questions.
What happens if one island in Network A federates with another island in Network B?
Nothing bad happens, nothing at all. Servers are still ultimately responsible for their own federation and can independently federate with other islands as they choose.
Do networks mean forced federation?
Not at all, it's creating opt-in networks, no one is forced to do anything. That said, not wanting to federate with several members of a given network means you might want to withdraw from the network and create your own, new network.
Who administers a given network?
Organize that however you want, that's outside the scope of this proposal.
Can't Nazis Create Their Own Islands? What stops them?
Yes, they can create their own, and nothing stops them. But you're telling me nazis want to create their own private networks, far away from us, and you think that's a bad thing?
Are you trying to kill the fediverse?
This is filling a need not currently served by the fediverse. It is ideal for refugees from the larger fediverse, creating a subset of it, utilizing some of the same principles of federation to create distributed networks of trust, denying bad actors an opportunity to exploit the open and unmoderated nature of denylist-based federation.
And the regular fediverse can still exist. You can have multiple accounts, nothing is stopping you.
So you could only follow other accounts within the Island network? What's the point?
Islands can federate with any accounts/servers they wish, island or otherwise. The point is to invert the security model and create an entirely different “invite only” subset of the larger fediverse. This is not creating a network, either, it's creating many separate networks, though there can absolutely be overlap between them.
One server might be found in multiple networks, which (generally) means that a server subscribes to all of the servers in a given network, and they are included in other networks as well.
Image Source: YouTube: Aeolia
Credit to Noracodes for coining the term “Social Archipelago” in the Fediverse is Already Dead
Can we improve the Fediverse Allow-List Model?
Looks like someone really kicked the hornet's nest recently on mastodon by announcing (not even deploying) a Mastodon-BlueSky bridge. Just take a look at the github comments here to get an idea of how this was received.A Division by Zer0
If you follow any of the #GoToSocial developers you've probably seen this going around already, but 0.17.0 of #GoToSocial will be the first release that includes interaction policies, aka reply-controls.In the first iteration of this feature, you'll be able to configure your account so that new posts created by you will have an interaction policy set on them, which determines whether your instance drops or accepts replies, likes, and boosts of your posts, depending on the visibility of the post, and whether or not an account trying to interact with you is in your followers/following list.
So for example, you will be able to create Public posts that can only be replied to by your followers and people you follow, or unlisted posts that nobody can reply to or like, etc.
GoToSocial interaction policies will be a superset of other reply control proposals created elsewhere (and already implemented by softwares like Pixelfed and Peertube), so your GoToSocial instance should recognize interaction restrictions set not only by other GoToSocial instances, but by Pixelfed and Peertube as well.
If you're interested in reading about how this will work on a protocol level, you can take a look at the documentation here: https://docs.gotosocial.org/en/latest/federation/posts/#interaction-policy
Please note that this feature is not 100% finished yet, and may be subject to change before release. We're aware of where the headaches and difficulties are, so please don't reply to this post griping about them; we already know (and this instance is still running on 0.16.0 so no interaction policies yet).
Thanks for reading :)