“It isn't a matter of forgetting. What one has to learn is how to remember and yet be free of the past.” ― Aldous Huxley, Island

This is my manifesto on Pelago, why it exists, what problems it solves, and how it proves out the exciting possibility and fragility of island networks, why federation of any kind will always need proper software to support it, and my quixotic quest to help build some of it.

I am sorry, this will be a long post. I beg the reader's pardon, with a quote from Blaise Pascal: I have made this letter longer than usual, only because I have not had the time to make it shorter.

I release this post now because I have been working on it for some time, and it's finally at the point that I either release it now at the length it is, or else I never finish editing it to a shorter length to release it at all. And I fear that my editing is in fact only making it longer which seems to betray the intent of editing, but my editor is me and he be fickle as fuck. [then let this right here be the final edit, no one is forcing you to keep going—Ed.]

Ha! Silly editor.

For almost two years I've been pursuing an obsession with trying to imagine and even build the technical and social underpinnings of how the fediverse could do federation differently that began with island networks, a.k.a. mutual opt-in allowlist federation a.k.a. allowlist clusters a.k.a. archipelagos, and has carried me through to the present. I think the obsession might be partly because this is something that is, if I might coin an adjective, uniquely fediversian. You can't build island networks anywhere else.

Is he talking about Bluesky, too?

Why, yes, invisible voice, yes I am. You set them up, and I'll knock them down.

The thing is, when it comes to Bluesky, outside of its composeable moderation, I find it largely uninspiring. So you built a giant firehose that needs to be centralized to really work properly and also costs a hundred thousand dollars a year and requires managing a fleet of technical and social infrastructure. Good for you! Meanwhile, out here on Grandpa's* Dimestore Internets, I prefer to own the entire means of posting without going broke. And by that I mean the whole thing from soup to nuts, which is something you can do with ActivityPub for a very affordable sum, versus something you simply cannot do with ATProto unless you're independently wealthy, or really good at kickstarter campaigns.

As such, since no one pays me millions or even hundreds of thousands of dollars for the promise of a “credible exit,” I like to focus on the kinds of things that only the fedi can do, the things for which it is truly best suited, on a budget.

I believe in the power of software to do good, because without software the fediverse or any networked online community wouldn't and couldn't exist.

We wouldn't even be talking about Mastodon or any online space without software.

So let's also build ethical software, the kind that can only be built on this technical foundation we're currently standing on.

So what can the fediverse do with its software?

For starters: it can build intentional networks organized around common agreements of whatever it is we think we're doing here. Which varies. Clearly. This is, after all, an army of very independent and contrary cats we're talking about. But I do believe there's a certain network worth building, the one some of us think we are in. For example, the Mastodon Server Covenant is one such common agreement, and it's arguably the default network, and it's ethical, specifically calls out white supremacy and transphobia specifically which is oddly revolutionary in a social media context, and is overall sensible. How that's enforced is a whole other headache (it largely isn't) but why couldn't it be? Why don't you just join the 'network of fedipact' or the 'network of necromancers' or the 'network of Mastodon Server Covenant' (a more community governance-based 'Join Mastodon' if you will) or the 'network of people who don't want to be moderated at all'? What if you knew which instances were part of which networks, so you knew which ones to join? What if, as a new instance admin, before you could federate with any of these networks, you had to first agree to certain rules or understandings, and if that wasn't your cup of tea, you just...stayed out of each other's way?

We'd all stop bumping into each other, if software recognized and formalized somewhat the true reality. It's not one network, it never was, it's many networks jammed into each other, all with conflicting ideas, as I've mentioned previously. Right now it's roughly organized into “those who moderate” and “those who don't” with a whole spectrum of arguments within the moderation band around how much and what you should moderate, and the spectrum of disagreement in those who don't moderate being what flavor of nazi bar they'd like to be.

This, via “composeable moderation” is something I think Bluesky does right: it recognizes that there are many networks and many ideas of what someone should get out of social networks.

But where I think we differ is that I don't think the firehose should be concentrated all in one place using a bunch of heavy vertical-scaled infrastructure to manage it that requires managing an annual budget.

What I like about island networks and allowlist federation is that it works with the small web model and shifts the usual paradigm, and formalizes and recognizes what is already happening, what blocklists and curation is already trying (and failing) to achieve.

As an alternative real-world example, I give you a simple island network, which would be the Island One Network, or ION. A simplified form of the Mastodon Server Covenant, it operates under just four simple rules: be excellent to each other, no bigotry, no brigading or harassment, no illegal shit (which is really just don't shit where you eat.) A starting point, a basis on which to build other networks, an archipelago from which anyone interested in creating an island or exploring the concept has an immediate audience and friend group in an archipelago based around four principles of doing what anyone worth federating with should be able to agree to—which ultimately amounts to the bare minimum of not being an asshole.

If that makes you feel a certain kind of way, let me reiterate: We're all here by choice. If you don't agree with the rules of the network, they are right there on the door. So if you are in the network, then you've agreed to the TOS for the network, so to speak.

Unlike the Mastodon Covenant's network, we can actually enforce ION's rules and that's because we control federation to the network itself. Even if someone joined the network and was abusive, the island in question suspends them and if they don't, the individual islands can just stop allowlisting that island, and worst-case scenario, we collectively can vote on their removal from the network. And because we don't allow open registration instances in our network they can't just create a new throwaway account and come back.

(Note, at least at this point in GoToSocial, revoking an allowlist entry while in allowlist mode does not sever existing relationships. Only a block does. Relationships will be re-established when the allowlist entry returns. Still unsure if this is an intentional behavior, but the lack of breaking federation is a nice feature and allows admins of instances to conditionally revoke allowlisting without concerns they will permanently destroy follow relationships. This turns it into a completely different discussion than an irreversible 'defederation.')

So this could be a unique feature here. It's one of the things we should lean into, because it's something that can only be done on the fedi.

You can't really do privacy on Bluesky, on most social networks, really. They are increasingly designed to do everything in public and in case you haven't been paying attention, doing everything in public is both handing your 'content' directly to AI whether you like it or not, but also to the feds who seem to think expressing an opinion online should affect whether or not you can get a visa, among other things.

I'm not really digressing, just pointing out that privacy is important for various reasons, even if you think you're saying perfectly legal shit in the 'land of the free' that won't get you in trouble because it's free speech and should be legal.

Yeah. About that. Moving on...

Starting the Island Network

Like all cars you build while still driving them, ION started with a lot of promotion and fanfare (including me posting Public instead of Unlisted for once, with hashtags, doing heavy recruitment for the idea), coupled with a lot of manual processes and bookkeeping. There were more than a few intrepid souls willing to take the plunge, some even started up islands specifically for this purpose, and them being willing to do so was truly inspiring. It's quite rewarding when people respond to an idea, following through with action. We collectively liked the idea of island networks and were willing to go through the growing pains of figuring out and exploring what this actually looks like in practice. Starting with the obvious: Does it even work?

You find out what you actually need when you follow through on a concept, and we hit roadblocks right away.

The primary problem we discovered was confirming that everyone's allowlist had everyone else on it. Confirming mutual federation between all members of the allowlist network is, it turns out, a royal pain without software.

This led, quite early on, to the creation of DM threads with each admin, where I was like “everyone please reply and confirm you can search and find everyone and that they are on your allowlist.”

It sucked. I'd have to nudge people and feel like I was being a jerk when really I just wanted everyone's allowlists to match up and then move on. But the hassle of getting all of that in place and getting everyone to give a thumbs up that they could federate with each other? Oof. There's a reason people haven't done this before now.

It was clearly a non-starter. Even at five or six instances it was painstaking. Just answering that one question alone: Am I on your allowlist and are you on mine? And then asking each participant over and over again, every time a new applicant arrived....How could that possibly scale to even twenty instances, much less hundreds?

It was so frustrating that I did what any person with coding skills would do in this situation:

I wrote software to do it, and that's Pelago. Literally. That was its origin and primary initial function: let a bunch of us login, escalate permissions to grant access to view our allowlists, and we'll privately just compare and see if we're on each other's allowlist, ignoring everything else. I don't care what's on your entire allowlist, just that the rest of the archipelago is on it. That's all the verification does.

You can view ION's federation, realtime, right now on its network page, if you scroll down to the bottom to the list of instances. The status of federation is right there, and whether the instance is up or down. It works and does its primary job. It's the bare minimum you need, in my opinion, to handle an allowlist network at scale.

What's In the Name

Pelago as a name represents the sea upon which an Archipelago is built. Understandably islands, continents, archipelagos and Pelago itself is a lot of new terminology, but I like the nautical theme and its open, optimistic view of the “whatever this is out here.” Aptly, it is open just like the ocean: free, wild, untamed, boundless. No one owns it, it is technically open to everyone and for many it's an absolute joy if you stay close to shore, but there are also monsters, dangers, storms, and tricks to fool the unwary, so wise navigators still take precautions, and islands, normally isolated, will still band together for protection and open communication channels between them—creating networks to organize and share information. That's island defense.

Thus, the 'ocean' of the fediverse is the entirely unclassified mess of whatever this is “out here.” An internet soup, if you will, a sea of ActivityPub, which is unfortunately plenty full of racism and nazis in its waters, in addition to its wonders and cats (and wondrous cats.)

How do we get a handle on it? What does the community think about this random troll or this random instance? Have we seen these actors before in any context, or any like them? Are they part of a trend or a one-off? Where's the signposts about this stuff, that won't get washed away by the tides, or off the chronological feed?

To tame, categorize, and organize our presence on that chaotic ocean, we needed Pelago. Like a pod of friendly dolphins, guiding a ship through rough waters.

See? The metaphors work.

Why Don't We Have This Yet?

Allowlist networks really aren't a widespread thing yet and it's because the software to support them literally didn't exist. Everything thus far has been oriented around “the continent”: blocklist-based federation.

We've spent all our time trying to figure out which instances are bad, but have we even considered which instances are safe? How do you discover new, safe instances to add to an allowlist?

People didn't even seem to know we needed this yet, so how could they even know to build it?

It's one thing to have an idea in your head, but if you can't describe it, if you can't build it as at least a proof of concept, and if you can't put it online so people can see how it works how do you even articulate that vision or make a case for it? People like vaporware ideas. They love shit they can use today even more.

So: does one in this scenario dare wait on anyone else's project timeline to do any of this kind of thing?

No, dear gods, I've been waiting four years for on opt-out checkbox for RSS from Mastodon. So impatient with their dev timeline I switched to GoToSocial. I'm too impatient to wait on anyone else's development timeline, especially when no one is paying me to do this, really. This is an expensive hobby. My reasoning is that there are moderation/federation needs now that can be solved with a little help, with technology we currently have right now. There's plenty of work to be done there and I don't mean to diminish it. But literally no one else was going to start exploring island networks unless someone tried it first, and started reporting how it's going, and started building tools to do it well. In an anarchic space, if it does not yet exist, then you have to build it.

There's an entire fediverse out there (or 'open social web' or whatever you want to call it) after all, and it's growing and changing all the time. You might want to federate with stuff or add it to your allowlist, but how do you know if some instance out there is safe or not? Is it on a blocklist?

Wouldn't it be nice if you could just look up a domain and find out what blocklists it's on?

Well, to do that: first step, find all the blocklists and....

Right. If you want to cross-reference an instance against its presence on blocklists, you need to ingest blocklists and track changes over time. How hard is that to do with flatfiles? Well, as someone who built that shit in about a weekend by myself, the real answer is not very.

That was feature number two of Pelago.

Blocklists: Adding Structure to Flatfiles

We needed blocklists on Pelago, preferably the kind that update over time, show change logs, retractions, with timestamps, basically change-tracking on remotely-hosted blocklist files....

And so that was the next major feature. A bridge from the old world of blocklists to what would become the new world of FIRES. I added change tracking, because retractions have always been the big gripe: how do you get off a blocklist and let others know you've been removed?

I didn't know what 'something better' that handled retractions was coming at the time, just that it was coming someday, but I could at least in the meantime give visibility to others about when something falls off of the list, or gets added to the list, or when, for instance, all updates might have ceased.

All features seem easy to build at first. I used to tell a former boss, “Look, just because you can explain what it does in a single sentence does not mean it's easy. 'Build Amazon.com' is a sentence.”

But change tracking was hardly all of it, now was it? I also wanted to cross-reference instances against blocklists. And when FIRES came to my awareness later, I also decided it made sense to turn these into datasets, since those also track changes over time. This was the “next thing” I was looking for, after blocklists.

So blocklists is a rather robust feature, more than just change-tracking on a flatfile.

It felt like coming full circle. “Oliphant does something with blocklists? You don't say.”

No. With that, Oliphant has finished his work on blocklists.

And yet....

That still left the larger problem unanswered for islands...who don't really use blocklists for blocking purposes, but rather to know whether or not they should add an instance to their allowlist in the first place.

The discovery problem returns, forcing us to answer important questions.

Who do you federate with? Who do you trust?

The missing features revealed themselves, one after another. Because of course it's not just about networking within a single network. What should stop someone from being part of multiple networks. What exactly does that look like?

Islands are a new thing, and something of a niche thing. You have to choose your allowlist, after all, you don't just auto-federate in allowlist mode. That's a big problem in and of itself. There's not a lot of us out there yet doing this sharing lists at all, and part of the reason is that we have no idea who the hell else to federate with. What goes on our allowlist? Is it vibes? How to express to someone 'these are folks running instances that seem okay'? Do they have common moderation philosophies, or is it all over the place? Do they even KNOW you're putting them on an allowlist? What if they want to say no to being on the 'Anti AI' list? Right. So.... if we could create allowlist-based networks where people opted-in to joining, rather than just being like 'here's an allowlist, pick those' that would more closely reflect allowlist federation wouldn't it?

It makes sense that if you're shifting to an allowlist culture, everything is opt-in, so no one should ever get on an allowlist without approving they want their instance on an allowlist. Simple enough, but also completely inverted in terms of usual opt-out permission structure (and general nature of federation) on the fediverse.

Not to mention the issue of enforcing any kind of agreements or applying any real security or privacy within a network, with all those open registration instances out there.

The Open Registration Problem

Aw shit. That's a new problem. What kind of 'closed network' do you have when anyone can just sign up? Shouldn't we track that? Is there a list of these instances somewhere?

Whether or not there was before, there certainly is now. I give you the Open Registration With No Manual review dataset, visible through a client-side FIRES viewer.

And yes, I create that that via scraping. The basic mechanism:

1. Find a publicly-accessible peers list.
2. Schedule a regular crawl over every one of those instances and check their /v1/instance and /v2/instance endpoints for their open registration policy. If registrations are enabled, and approval_required is false? You go into the dataset.

This is admittedly a form of scraping, the very thing that people tend to hate on the fediverse, but I think this is a very defensible use of it.

Let's be clear what I'm scraping, and why:

I'm scraping whether or not your instance is freely available for random signups and block evaders and scammers and spammers to build quick throwaway accounts that will continually, forever and ever, be everyone else's problem to solve. The status of your open registration review process (or lack thereof) is certainly not unknown to them. If we federate with you, as an open registration instance, you have outsourced your moderation to us, hoping we'll discover someone for you on your own server: an AI account, a white supremacist, a troll hurling hate speech into someone's DMs, whatever, and report them back to you and also hope that you respond quickly in response to that report before they have time to continue their abuse, or else everyone else has to block that person because you won't.

Federating with open registration instances is a devil's bargain. It's where most of the people are. You feel like you can't block them. Suspending them means cutting people off from their connections. If only you could limit the default behavior from those instances, though, categorize them as 'hey, manual follow approvals for everyone from these instances, please' and 'put them on mute.' (which, calm down, doesn't affect posts from existing follows)

It turns out, you can (thank you, GoToSocial domain limits api), but first you need to know what those instances are. And you also need retractions, in case someone turns off open registrations or turns on manual review, either of which auto-removes you from the dataset, and allows others to make decisions accordingly.

It's still not nearly granular enough of control, we should also be able to reject replies from open registration instances as well (again, unless there are existing follow relationships), but that gets to FIRES and a need for filters and composeable moderation. This is what we have now.

So, no, I don't feel guilty about building in this kind of a scraper, not one bit. This is a public service. The fediverse absolutely deserves to know about the currently 800+ known havens where the rando white supremacist Trump dork you suspended can create any of potentally hundreds, or even an entire botnet-worth of harassment accounts. I mean, they certainly know which instances are leaky places where accounts can be created and often never suspended; even after revealing to the admins of those servers that they are abusing the system. Why shouldn't you?

When people talk about scraping they mostly mean you. Your data. Your account, your posts. That's not what this is, and I don't care about server statistics, I just want to know if you'll let just anyone sign up or not. What version of software you're running (for compatibility reasons, but also because an unpatched server is its own threat analysis.) So I'm outside the front door, like an inspector, checking the meter, scribbling it down in my notebook, and moving on. You're open registration. Hmm. Confirm email, that's it? That's your approval process? Hmm. Okay. Noted. checks something down in the notebook with a frown. I don't hate you for it. I just realize I have to treat your instance differently and put in a little extra caution, that's all, and in the context of island networks that sort of rules you out of being recommended enthusiastically for any sort of allowlist at all. Nothing personal.

Island or otherwise, this is information the community deserves to know and if you hate that your instance is on that list and anyone, any bad actor can just decide to make a home on your instance now that it's on a list? Consider me like a security researcher who just identified a vulnerability, and fix it.

Feature Creep: Because Stuff I Needed Kept Not Existing

Inclusive in taking opinionated stands on the inherent insecurity of open registration instances, Pelago as software is a manifesto itself.

Ultimately, the featureset became larger than just islands. Pelago has become a federation toolbox and bulletin board for all networks of instances, islands or otherwise. It recognizes both worlds....supporting those who live in this world on “the continent,” but building for the next world, more island-centric. Or for those who are trying to live in both.

So we have tools like instance inspection so we can look up any instance, and see if they are on a blocklist or have any warnings against them, or active community reports against specific individuals on their instance, or review their rules, or perhaps we can find out in doing so that—for example— uno.1sland.social is in the ION network, and that I run that instance, along with the rules and terms of the instance are (if any), and whether it is accepting registrations currently.

Each Pelago pod populates its own Community Reports dataset full of recommendations, populated by community reports of problems, kind of like #fediblock, maybe even originally sourced from fediblock in many cases—both domains and actors being reported, going beyond instance blocklists to actor blocklists in the form of FIRES advisories and recommendations. But it also works as Pelago's internal blocklist—it must abide by its own recommendations in that respect.

So anyone can report a bad actor or a domain which creates an advisory and is shown on the evidence page for that actor visible on the main report feed, and then empower community admins to decide if advisories should be promoted to recommendations, or else retracted; logging everything for visibility, with the entire feed being an auditable public FIRES dataset.

The features of the platform grew organically over time as they were needed, as challenges of coordinating moderation of scale became increasingly obvious, because the problem of federation and allowlisting good actors, while blocking or avoiding bad ones, is a really big problem. And ideally, you need to let those accused also answer for themselves, contest the ruling, and allow for retractions.

Every feature ultimately dovetails together, one supporting another, all combining to classify and categorize and build “islands upon this ocean,” to provide you a way of actually seeing, building and governing the networks that technically already existed, we just didn't have a way of organizing them before. They weren't structured yet or represented in a way we could manage. How to collaboratively edit the settings of a network itself, its governance model? How do you orchestrate that at scale?

I've been pursuing a vision here: trying to reimagine federation and how we do it, how we stop drive-by harassment and zombie unpatched servers, how do we catalog the spammers who create 100 accounts, and like maybe we should collect them all under a group evidence page for easy sharing and distribution....

Yeah, it does that, too.

Privacy and GoToSocial

Let's talk about #GoToSocial, in particular its posture on privacy, and why I think that's important, and I'd even go so far as to say inspirational to me in the development of Pelago.

GoToSocial came into my attention early in this process and had all the goods: privacy features, opt-in for EVERYTHING as far as sharing your content publicly, Unlisted by default, markdown authoring, secure fetch, cheaper to host and all that good stuff, RSS feeds aren't on by default!, and then the real turning point: they added domain subscriptions, where islands could literally auto-subscribe to shared allowlists—hidden behind basic authentication—a nice feature from GTS that allowed for the creation of private island networks, island networks that have an allowlist accessible only over basic auth.

Once auto-subscription/ingestion of allowlists was on the table, we had everything we needed to automate federation, so long as we all had the same source of truth for our allowlists, and used the same system (Pelago, of course) to synchronize it.

As it stands, an individual island's allowlist in Pelago is protected by basic auth by default. This was done because GoToSocial added it as a native feature before I could even think of how badly our network (comprised entirely of GTS instances) needed it.

While the ION network allowlist itself is public, the idea is that your unique combination of instances you federate with is your business—and the business of people on your island—so you get a unique allowlist URL that includes ION's network membership—but also any other networks you become a member of as well, all secured behind basic auth, by default.

Your whole island's full allowlist across network memberships never has to be divulged to anyone. Especially important, because private networks are a thing.

This feature of securing the allowlist/blocklist—a feature GTS just added and didn't even have to—literally no one was asking for it, changed everything.

Because we needed it. We didn't even know we needed it until we had it. And that's magic: Someone looked ahead and thought privacy-first, with ultimate respect for the user and what they choose to share to the public.

That 'privacy-first' nature, not to mention a focus on island federation and desire to make islands a first-class citizen of the fediverse in some form of software out there, forced me to consider every problem through the lens of federation as a choice or a privilege, rather than a right we just assume by default. Don't assume people want a public network, want to create a public dataset, or a public anything for that matter. If they file a community report, give them the option to share their name publicly along with the report, but assume privacy by default.

In many ways, the software feels a bit like me taking an opinionated stand on how I think stuff should work or maybe could work, what the gaps are, with the underlying principle that once I've demonstrated it in action and once I've built all the features, people will start to see how it all fits together and we'll have a system that actually works to create truly safe, private, well-moderated and accountable networks. And then they'll basically take my ideas and build something even better...but until then? You should log into Pelago and see if any of the ideas work or resonate for you.

Stuff like conversations and discussions we can moderate and control, not just at the discussion level, but at the network level, too.

The networks were invisible, they were never surfaced in the software. So to be able to start creating them and seeing them and populating them, to support the people part of the system, I needed to create a system for people to organize and govern networks online. Networks that have something to say about managing consent-based federation.

It's all just networks? Always has been.

For an island, there's still a discoverability problem of what goes on the allowlist, not all islands want to federate with just other islands but regular ol' instances out there in the fediverse, so where's the moderated allowlist that enforces certain shared boundaries? Where does that exist?

It's just another network.

Networks aren't just archipelagos, and not just for islands. They are just a group of admins (and their instances) that tend to care about or organize themselves around similar ideas. Networks for regular instances to band together and call themselves the 'Anti AI alliance' or 'The Monsterdons' or whatever, and allowlist all the instances that follow the code of the 'Anti AI Alliance' or whatever.

And then islands wanting to know who to add to their allowlist just find the 'anti AI alliance' network and subscribe to it or maybe even join the network, putting themselves on the allowlist, too. And there'd just be software to say, as an instance admin: “we're part of this archipelago, but we're also subscribed to the Monsterdons and we're members of the 'Anti AI alliance'” and then a composite allowlist would be created from your own island's unique combination of network subscriptions to produce your final allowlist, and a GoToSocial instance or (coming soon) Mastodon instance could just subscribe to that and ingest it, and within 24 hours or so of a new instance joining the archipelago, everyone is mutually federated.

So that part actually exists and was the first thing I built for Pelago: island networks, confirming mutual federation, producing of allowlists that can be auto-subscribed by members of the archipelago to sync up our allowlists and ensure everyone can federate with each other; and then added an invite and a 'join/apply' component so new island admins can just apply to join, so we can approve their application and boom, they are on the allowlist.

After which comes the next problem: You're on an island but how do you send a message to just your network. Or just a specific network?

How do you target that?

Discussion Groups

Before I knew it, I was doing the ol' ActivityPug myself, and after a few weeks of rather obsessive work, the Island One Network is now a federated network actor, too, it has programmatic opinions on whether you're allowed to follow it or not (based on an instance's membership in the network or not), and anyone on any of the islands that comprise its allowlist can follow that actor (so long as they also allowlist pelago.1sland.social). And specifically only people on one of those instances on the allowlist can follow that actor. If one of those instances leaves the network, it will automatically force-unfollow everyone following the group. The discussion content stays within the network or group, because that's how Followers-Only works. (There's peculiarities to this in practice, see the docs.)

So with the latest private discussion groups feature in Pelago, you now have the ability to federate with anyone you want, but essentially target and scope messages only within the followers of a given actor—and you just need to be able to control who is allowed to follow that account in order to scope conversations.

If I send a private DM to @ion@pelago.1sland.social I reach the entire network. I can log into Pelago and see it there, as a thread and others can reply and comment directly in Pelago.

And everything I did there, you can do, too, just logging into Pelago. It didn't require special tools. You can create a network or a discussion group. It's part of the software right now.

FIRES and Subscriptions

The FIRES protocol, created by @thisismissem@hachyderm.io has become a core feature of Pelago. It's a bit beyond the scope of this document to go into it in detail, but every blocklist also creates its own FIRES dataset in Pelago, and there's a subscription area for FIRES, there's a dataset viewer or an entire standalone view of the Pelago server at its FIRES-branded URL fires.1sland.social.

I've attempted to mirror the FIRES Reference Server implementation within Pelago (including the same data structure and mostly the same queries, v7 UUIDs for ordering, etc), but if you want the actual canonical reference and are intending to re-implement the FIRES protocol yourself, you should start there. I'm pretty confident I've mirrored it as close as possible in terms of the existing published API, to the point where I've even compared outputs between Pelago and the FIRES reference server to my satisfaction. Submit bugs as you find them, of course.

Technical Note: One difference between Pelago and the FIRES reference server is that Pelago stores the entire IRI for a label, to support labels from other sources besides Pelago, which is intended by the protocol.

At the time of this writing the Community Reports dataset is the only active dataset I'm aware of being used for moderation purposes that contains recommendations against not just domains, but also actors. You know, actors in an ActivityPub sense: Folks with a handle. That makes it the only syndicated moderation feed that exists right now that can apply recommendations against actors, not just domains.

A clear evolution beyond blocklists, to the point where blocklists now feel dated.

A Final Word on Pelago

Final. Ha. As if I've ever finished talking about anything. The reason it took so long to write this post is because this is a moving target. Pelago isn't finished, and may never be finished. It may never need to be finished. Perhaps Mastodon, GoToSocial, Akkoma, etc, will truly embrace FIRES and bring it into their platforms. I certainly am betting on it and hoping that they will. If they do, the FIRES subscription features won't really be necessary in Pelago.

But I think many parts of it will be relevant for a while. The data provider FIRES aspect of Pelago is still needed. And the concept of creating networks does not have a parallel anywhere else yet, although Bonfire has taken on Archipelagos with a vengeance. But even once you have archipelagos, you still need the means to manage the network it represents or handle consensual federation, otherwise you get dead zones in the network without reciprocal allowlisting. Which means you'll need to confirm federation between the members of the network at an allowlist level (or other means) and if that fails you'll have to have a way of messaging the island in question that it's missing federation so it correct it, or else the archipelago will need to grant not just read permissions, but write permissions to the allowlist as well (Pelago has not taken on that permission yet, but I might provide it as an option.) And if you're managing a group, then suddenly you need to factor in governance. So you're going to end up building something with features similar to Pelago, for islands.

That's already a lot of reasons people have not tried to solve this problem yet, why the default has been “good enough” for too long. Why not building this has been easier than just adding another “blocklist patch” to an endless and sisifean task of focusing on what we do not want instead of what we do.

Pelago has a stack of features building on a stack of features to ultimately turn islands into first-class citizens, in a world seen through the eyes of willing, intentional, consensual federation. That's not a common view yet, maybe it never will be....but I think it is a great evolution over what we have right now.

And you literally cannot build that on Bluesky, or anywhere else. We should lean into that. This is an entirely unique experience, brought to you by the ActivityPub and FIRES protocols (with some extended help from Mastodon's API.)

See what's possible when you aren't trying to re-build Twitter all over again?

Addendum: Some Needed Credit Where Credit Is Due About Island Networks

An “Addenum” after the “Final Word?” Is this a joke???

Silence, invisible voice!

Let us not close without giving proper credit, and some disambiguation.

“Island One” was not actually the first island network. People have been doing allowlist networks ad hoc for years (even calling them different things, like “allowlist clusters”, etc.) I don't even take credit for coining the term “archipelago” in a “fediverse” context. That goes to Nora Codes in “The Fediverse Is Already Dead”, which is also foundational reading, in referring to the “Social Archipelago.” I did not intentionally borrow so heavily from this metaphor. Sort of a process of parallel evolution. I did try to synergize “islands” with “island networks” with “archipelagos” and the notion of an “island” as an alternative to “instance” style federation. “Island” just rolls off the tongue better than “an instance that runs with allowlist-based federation, also known by Mastodon as “limited federation'.”

As for the name “island” itself, I was thinking of it originally as an “outpost” concept rather than island, but @tobi@goblin.technology (lead developer/creator of GoToSocial) suggested that was too militaristic of a theme, and fair point there. We aren't under siege here or hiding. We're reaching out and building connections. I took a poll with some options, island was most popular alternative to 'outpost'. And a band of islands is an archipelago. And the rest is history.

It was not even the first network to call itself an island network. That honor goes to The Website League. The Website League took the same idea: build using existing software (GTS/Akkoma) and hack it to work more Cohost-like (no reactions for one, I don't think) and chain everything together in an exclusive network. It's all allowlist based and doesn't federate with the rest of the fediverse at all. You can join it yourself. This is what I call an “Exclusive” archipelago. The other two options are “Closed” (you can join other networks, but those networks must be archipelagos and you're only federating with other islands), and “Open”, like ION (islands can federate with whoever they wish, island or otherwise.)

The Website League has it all working in practice: They own the network, and they have a really devoted core membership that are having conversations that “the Continent” will never know about. They aren't yearning for “all of this” out here, or if they do, they have an account out here, too. Yes, y'all, you can have multiple accounts for different audiences or networks if necessary. But they are using most of the same apps to talk on their network, and it's all ActivityPub, and when the needs of their network fall short, they can create or modify existing software.

There are shout outs I've already made that should be made again, like to @thisismissem@hachyderm.io who is a truly skilled and ethical developer, and far more organized than I'll ever be at anything. She is well-deserving of your support if you care about moderation and alternatives to 'blocklist' federation, as she works for the fediverse largely on moderation-related features, developed most of the major Mastodon moderation features as well, not to mention created and continues development on the FIRES protocol. She's that xckd meme, the block holding up a lot of the moderation infrastructure of the “fediverse” itself.

Another repetitive but deserved shout-out to my slothy spirit animal of a platform GoToSocial which consistently nails it in terms of features and priorities, user privacy, security, ethics, and general punk rock attitude, and is the current backbone of ION's Archipelago. #piss

Extra special mention in that vein given to Bonfire for building an Archipelago mode, embracing the idea of island networks, and in general building principled software that reimagines what federation can look like.

And to all the other work going on in this space that already exists, that I haven't mentioned, either because I ran out of time or I'm just unaware of it, I salute you as well, forgive me for your omission. You are here in spirit.

Ethical software development can and does exist. It's just harder, and it takes longer, but it is worth doing right.

I think that brings us full circle.

* I'm not a grandpa and not even really that ancient yet (have I truly earned Old Man?) But why mess with a good line?

Other Stuff:

• Read more about Islands

• Read the docs (Just like Pelago, they are a WIP)

• Tips welcome: I'm not too proud to beg, I don't get paid for any of this really, so feel free to fund the shit out of me. I'd do it without your help, too, because I can't help myself, which is a terrible sales pitch....but if you'd like to defray some of my financial stress, it would be appreciated and probably avoid me hitting inevitable burnout sooner. Things tend to be a passion until they are not. Sometimes they are also expensive passions, in terms of time, financial cost, or psychic damage from too many nazis or shit no one should see on the internet. I'm just saying.

• I have barely even touched on the social aspects of running island networks or networks of any kind. Governance is a big issue, and while I now have software that supports different models of running a network, enough so that changes of leadership, invites and removals and moderation decisions for the discussion groups are all part of the workflow. But I have little to report on how that works at large scale. At ION's modest scale we're all getting along just fine, so we've not yet had to make a hard decision.

• If you care about such things, none of this was written by an LLM, because it took me three months to finish writing it.