destructured

Design is social.

November 17, 2023

Groundedness and community

On the potential of truly decentralized social media

When Elon Musk bought Twitter at the very end of October 2022, millions of people set out to find a new social media outlet. Much of the discussion since then has been framed, particularly by journalists, around the question: Which Twitter replacement will succeed? Mastodon? Bluesky? Threads? People often answer in terms of familiarity—which alternative most matches the user experience to which they’re accustomed. No doubt, there people who would be happy with a service that’s exactly like Twitter was circa October 30th. But that desire leads to frustration as their choice of Twitter replacement gradually begins to grind up against not just their expectations, but also their values.

Values, after all, are what drove much of the initial flight away from Twitter. Those values may include whatever made you recoil from Musk’s leadership. Maybe it’s a value that interested you in decentralized and/or federated design structures. Maybe it’s a belief in grassroots/independent tech. Maybe you’re just fascinated by the possibilities of new tech.

The point is: Take a beat to think hard about the values that inform your decision-making around social media. Naming those values will help you be consistent in applying them. For my part, I could name a few:

It’s debatable whether Mastodon—or, for that matter, the fediverse as a whole—really fits all of those values. But spelling them out equips me to make more conscientious decisions about how I use social media. It should also serve you as a basis for assessing everything that follows, as well as a reminder to distinguish between what it would be nice to have in a perfect world, and what can be obtained without breaking the balances that preserve our values. The features and structures that our experiences with social media platforms have taught us to expect may not necessarily be desirable in view of what we really value.

Platform thinking

One immediate beneficiary of the Twitter exodus was Mastodon, a social media suite built on free and open source software (FOSS) principles and using the ActivityPub (AP) protocol to interoperate with other AP services. New members flooded Mastodon servers in November of 2022, and in successive waves each time Twitter announced an unpopular change thereafter, which was often. Yet each peak was followed by a trough as people initially excited about the prospect of an open, non-commercial social media network ebbed away.

Sometimes I think that our first mistake was talking about all of these distinct but interoperable servers as though they were one big platform called Mastodon. Are you on Mastodon? we ask. I saw it on Mastodon. Let me check Mastodon.

Mastodon is not the network, though—a misperception that we immediately begin walking back as soon as we’ve talked someone into joining a server (called instances). On the one hand, we explain, you can communicate with people who aren’t using Mastodon at all, but rather on one of a few dozen different services that interoperate via ActivityPub. On the other hand, we add, you can only communicate with people on servers that are “federated” with your own.

As such, the potential network available to any given instance member will be larger than Mastodon, and yet almost certainly will exclude many Mastodon servers. The wide-angle view is encapsulated by the word fediverse, meaning all of the instances that federate via ActivityPub, whether or not they in fact federate with your home instance. Which lets us put the word network to more specific use, as a way of gesturing toward the web of relations that actually connect people and servers to one another. To some extent, those relations are determined by the structure of a service, like Mastodon, but compatibility via ActivityPub ensures that the network available to you is not limited to users of the same service.

For most critical concerns (e.g. administration, trust, moderation, peer access), instance is more fundamental than service. We could reflect that priority by talking about server before software: I’m on merveilles.town. It uses Mastodon. Historically, though, we’ve been content to set the wrong expectation. Even telling people that choosing the right server is the most important step in joining—or advising them not to agonize over the decision, which, after all, isn’t that important—gets the priority backwards. It’s framed as an onboarding decision about Mastodon, when actually it’s the server you’re boarding, and Mastodon-compatibility is a factor in that decision. (I’m on merveilles.town. It uses Hometown. That’s a variation on Mastodon.)

It’s no wonder people get confused when you tell them that the first step in joining Mastodon is to pick a server. It’s the instance, not “Mastodon,” that you’re actually joining. There is literally no way to sign up for Mastodon. Because, again, there is no one Mastodon to join—just a bunch of instances that federate in various ways.

We could talk about corporate social media platforms the same way: You’re on twitter.com, which uses Twitter. That syntax is just as accurate for Twitter as it is for Mastodon, but we generally don’t think of it in those terms because twitter.com is the only server that runs the Twitter service—or looks that way at least: twitter.com is actually thousands of servers, all resolving under the same domain.

That way of bundling together the major conceptual features of social media is part of what’s implied when we talk about Twitter as a platform. The last two decades have trained us to think in platforms. We associate social media with platforms because the companies that have, since the early Aughts, been synonymous with social media, have all enforced a very close conceptual tie between server and service. Twitter (the company) could, in principle, license Twitter (the software) so that independent operators could run it on their own servers in parallel with Twitter (the domain). Instead, they kept it all siloed as a single platform.

(The distinction between those layers was inadvertently made clearer when Musk changed the name X, and everyone had to start calling it “X, formerly Twitter” to indicate that they were, indeed, talking about the same service.)

Enforcing a structural break between software and service provider is a step toward decentralization, one of the ideals behind the development of Mastodon and other (though not all) AP-based services. The concept is fuzzier than we sometimes admit. Is spreading a service across multiple independently operated servers sufficient for decentralization? Or does the ideal also require a redistribution of authority? To what extent can we call a network decentralized if the vast majority of its users are crowded into—and most of their interactions take place on—a single server? Is federating with other servers and allowing users to move their accounts to another service enough to decentralize a platform? Or does decentralization require decoupling so that the service itself can be run by third parties providers? Thorny in their own right, those questions become intractable when we habitually view platforms as the paradigm of what social media should be.

The persistence of platform thinking is often manifest in the expectations we bring to decentralized social media, as well as in the demands we place on its development. One reason acclimating to non-commercial social media can be so disorienting is that many of the features that commercial platforms designed to mine us for monetizable data were pitched to us as matters of convenience. We valued those features for the social practices they afforded, but the platforms never held onto an idea that didn’t benefit them as profit-seeking companies. The affordances that stuck were those that cut both ways, not only affording us ways of communicating and organizing online, but also giving service providers and advertisers tools for reaching and cataloguing us and our communities. Then we arrive on the fediverse, expecting those same conveniences, only to have that expectation disappointed. The desired feature is harder to operate on a decentralized network, or it may be risky in ways that weren’t obvious on the platform, or the incentives aren’t the same.

And yet, what I find most frustrating about the drive to recreate the features of commercial platforms is not how it paves the way for commercial interests into a previously non-commercial space, but rather how the unexplored possibilities dwindle the more we tailor these spaces to visions of the past. What was most valuable about those features were the affordances that allowed us to build vital social practices, but we no longer seem to recognize the element of compromise in that arrangement. On the platforms, we had little choice but to structure our relationships around whichever tools seemed most promising to companies seeking to monetize our interactions. Freed of that compromise, we could be building tools that facilitate the relations we want, rather than clinging to those that were merely afforded to us.

Now that the platform companies are experimenting with federation, the interval we have for building new structures without corporate permission may be growing short. Yet, if we’re going to make the most of the opening up of social media, it will be necessary to move beyond platform thinking. That will require settling into different ways of talking about the basics of our relationship to the technology. People are understandably reluctant to leave platforms where they’ve built communities, but imagine what we could do with tools designed to support those communities, not just extract value from them.

Grounding

The big challenge for decentralized social media may be figuring out not community, but rather groundedness. Part of what I mean by grounding is: A community is not just something you speak into, but more fundamentally, a social relation out of which you speak.

To illustrate by negation: Reddit lets you float between “communities” because your account is grounded in the platform. All accounts are Reddit accounts, and your relation to any given “community” is one of subscription. You may jack into any number of subreddits, but your account stands outside all of them. That, in turn, makes community connections functionally weak. When we talk about subreddits as communities, we may be speaking both metaphorically (“subreddits function like IRL communities”) and/or aspirationally (“subreddits facilitate offline communities”), but one fundamental provision of community that it’s difficult to get by subscribing to a subreddit is grounding.

That may be the condition of “community” on social media platforms writ large. In may ways, they are platforms by virtue of hosting all accounts and whatever communal forms connect them. As a result, everything is grounded in the platform, and connected only secondarily by the semantics of the service. That may resemble freedom of association so long as the company is relatively laissez faire about administrating it all, but the real relation reasserts itself whenever the company intervenes.

Structurally, ActivityPub provides greater opportunity for grounding accounts in communities, if only because accounts are hosted by independent servers. People who want account mobility tend to see that as a major drawback of decentralized social media (never mind that you can’t move your account off of Reddit or Twitter either), but it can be (though isn’t necessarily) the basis for a more analogous form of community grounding than we find in other social media structures.

Because fediverse accounts are hosted by instances, there’s much greater potential for grounding online presence in a community here. Your home server is a social relation out of which you speak into the larger network of which it is a part. That doesn’t necessarily make it a community in any substantive sense of the word, but it can be a basis for building community. There are other conditions we have to work on in order to “figure out community,” but most of those conditions begin with grounding. Groundedness is a precondition for building.

Bluesky presents another potentially illuminating contrast. Whatever rationalization its developers may offer, the primary problem that Bluesky solves is the difficulty of monetizing the data generated by people who aren’t on Twitter. (Bluesky began as a Twitter initiative.) Bluesky solves that problem by dispensing with the platform, replacing it with a protocol, and structuring that protocol so that it only works by harvesting nearly every data point generated by an account. You can run your own instance and connect it to the network at large, but only by making all of the data it generate available for their profit.

I still don’t see many people really grappling with the notion of “decentralization” that entails. Bluesky accounts are more portable than ActivityPub accounts in part because they’re only nominally hosted on account servers. Everything essential to the account is stored on a massive indexing server. You can ditch your “community” at the drop of a hat because your persona is really grounded in the cloud. Indeed, much of the protocol seems structured to route around localized community. Similar to Reddit, what you see via Bluesky is largely subscription-based—you choose an algorithm served by a remote, third-party server, and it builds your timeline. If that’s the basis for “community” there, then Bluesky communities will necessarily be mediated by black box decision-making. We’ve only begun to grasp the Orwellian potential of that structure.

Nodes and networks

Platform thinking makes it difficult to be consistent about our goals for a decentralized social network; lack of clarity makes it difficult to talk about decentralization at all.

Particularly for new arrivals to the fediverse, the common assumption has been that Mastodon is the network, and that the job of an instance is to connect accounts to Mastodon. By and large, the most populous servers have catered to that assumption by operating as neutral carriers, placing themselves in the way of the free flow of communication only when safety unambiguously demands it. That circumstance tends to reinforce a particular understanding of decentralization—that instances are Just Nodes; that their primary function is to connect you to the larger network; that how each instance is administrated matters for sustainability, but not much else; that more creative administration can only undermine the instance’s utility.

The Just Nodes point-of-view follows naturally when you approach a decentralized network by way of platform thinking, but contrasting visions are possible. One of the more interesting characteristics of the fediverse is the Janus-faced nature of instances. They can face both outward, to the larger network, and also inward, to the local population. That’s evident in Mastodon’s Local timeline, and even more so in the Local-only posting option offered by forks like Hometown and Glitch. It is, though, an affordance implicit in the structural break between software and service provider, and what it affords us is the opportunity to build instances into more than Just Nodes.

If nothing else, inward-facing functionality stands in support of the sort of self-governance instances often need in order to sustain their own operation. They make collective decision-making easier, and help account-holders pool resources when it’s time to pay server costs. They also make it possible to operate instances as gathering points for community, valuable not only for their ability to connect members to the fediverse at large, but also for the relations and interactions they facilitate locally.

To an extent, this happens already. There are servers organized around hobbies, around locations, around expressions of identity. To one degree or another, they all share a Networked Communities perspective on what an instance could be. I suspect that we have only just scratched the surface of what’s possible when we adopt that point of view. With more innovation, more development, and a clear sense of purpose, we could build on that dual-facing vision: Instances as collaborative spaces that connect groups to the world at large.

Instances administrated according to a Just Nodes perspective aren’t necessarily incompatible with the ideals of Networked Communities, but the two lend themselves to different approaches. I’ve seen it suggested, for example, that de-federation should be reserved for hopelessly abusive instances—sometimes with the implication that even less stringent limits are likewise a bridge too far. And that makes some sense if an instance is only an access point to the network at large, but that need not be the only way to conceive of your instance’s relation to the rest of the fediverse. Shifting to an emphasis on building and serving a local community makes decisions about when and how to federate an expression of the needs and values of that community.

It seems to me there’s a deeper kind of isolation in the view which says the servers that matter most are those that merely face accounts outward toward the network so they can shout into the off-brand Twitter-hole. Social media platforms turn everyone into an atomized individual scrabbling for attention. It feels like a poverty of vision to maintain that what distinguishes Mastodon most from Twitter is the ability to host accounts on your own server. Running your own instance can be a way of serving an underserved community, of implementing more copacetic standards, of setting up firewalls between you and hostile communities, of ensuring account longevity. More than that, it fosters the conditions that allow us to push at the limits of platform thinking, thereby changing what can be done through the social media. Decentralization and decorporatization are not the end goal, but rather steps toward a polyphony of more expressive visions that reach beyond a pitch that effectively reduces to “Own and operate your own shout hole!”

I can think of a number of servers where the local rules and policies articulate a reasonably clear ethos, but maybe the message that “we are not a neutral conduit to the network” is left a little too implicit. Servers should have a strong idea of what relation they hope to build to the rest of the fediverse, express it clearly to their members, and moderate accordingly. They should spell out to prospective members what criteria that use for applying moderator actions to other servers, and make it clear how those policies condition their access to other parts of the network.

Increasing transparency about how a server views its relation to others can go a long way toward defusing the disputes that sometimes arise over administrative decisions. Fediverse drama will tend to be more empassioned than drama on corporate social media, if only because people here often have a bigger stake in the spaces they inhabit. They helped build them, they rely on them for a certain degree of UX tailoring, lots of times they’re paying to support maintenance. In myriad ways, what you do on the fediverse matters more to the ecosystem than it would have on a corporate platform, and that makes it harder to take server disagreements as “just the way it is.” Nor should we. But understanding the prerogatives that drive instance administration can go a long way toward setting expectation. An instance that is beholden first and foremost to a particular social form will necessarily act on a different set of imperatives than an instance where the only prerogative is to connect to as broad a network as possible.

That doesn’t negate the need for a concerted effort to be constructive or civil or empathetic. If anything, the fact that the fediverse invites more involvement at the decision-making level ought to convince us of the need to be better listeners and bridge builders. We have to be alert to the needs and experiences of others, even as we advocate for our own. At a certain level, not accepting “just the way it is” is the whole reason we’re here, but platform thinking is an ingrained habit. Overcoming it requires, first of all, diligence of thought.

Networked communities

Over time, the Just Nodes view tends to increase centralization. If access to the network as a whole is all that matters, and instances are just ways to connect to it, then the only real limits to how many people you can and should pack into a few big, “generalist” instances are performance and safety. And to the extent that it favors instances with hundreds of thousand or even millions of accounts, Just Nodes creates huge potential points of failure for the network. At a certain point, selling to a for-profit entity or reincorporating as a for-profit becomes the only viable solution. That dynamic suggests that the more we position instances as Just Nodes, the likelier it is that some platform corporation (like Meta) will eventually swallow large swaths of the fediverse whole.

The Networked Communities view, by contrast, tends to increase decentralization as people launch more small instances to cater to bespoke communal needs. The best way to preserve decentralization while helping grow the network is to concentrate on growing communities first, and let the fediverse grow as a side effect of that.

The fediverse is highly self-reflexive, and there’s a constant tension between feature-oriented discussion and structure-oriented discussion. It’s sometimes said that, however ideologically preferable it may be, decentralisation makes the user experience worse. And that’s certainly true if you build around the expectation of a platform-like network where everyone is floating through the same nebulous, borderless space. But social media doesn’t have to be structured that way. The structure of grounding accounts in instances may be limiting when it comes to a lot of the features that people would like to have, but it opens up some radical social possibilities that we’re only just beginning to explore. We can begin by building around the idea that we each inhabit self-contained virtual spaces that can be linked to one another in constructive (and, if we’re not careful, destructive) ways. Which is, in fact, how federation works.