Progressing Fringe Mastodev

Journal: \u2764

This entry is a much‐belated resolution to my indefinitely‐suspended blogseries, Fringe Mastodev, first written in the back half of 2018.  The following sentences, which appeared at the beginning of each post, summed up the unproven thesis of the series:

Fringe development is my term for the development work (research; design; coding) taking place on forks and individual instances of Mastodon, without the intention of sending that work upstream, and without mainstream acknowledgment or recognition.  Increasingly, as Mastodon as a project grows, I believe that it is this development work that happens on the fringes that will shape the future of the software.

Although these posts do an acceptable job describing the culture and situation into which fringe Mastodon development first emerged (in the form of the GlitchSoc fork), the final conclusions—regarding the radical potential, as well as the dangers, that these development practices hold—were never reached.  And, in the time since, new developments on the fediverse have emerged.  This Journal entry picks up the mantle of fringe Mastodev analysis once again, in an effort to see these posts to their conclusion.  It will begin by recapping, and analysing in context, the original posts, as well as discursive developments on the fediverse which have followed their publication.  It will then retackle these older arguments and resituate them within the contemporary fediversian context.  Ignoring the argument at scale, it will analyse small communities and question the assumptions which underlie how they are currently conceived.  And it will push at the boundaries hitherto expressed about the forms that these small communities might take.  Finally, it will take a critical look at the forms of power which might perpetuate, even/still, into this new frontier.

Introduction

I wrote the original four Fringe Mastodev posts in the aftermath of my (formal) departure from the GlitchSoc fork project (and glitch.social network of instances), which came approximately six months after my (informal) hiatus from working on the project.  In this sense, I wanted the posts to serve as a sort of capstone, which they did, of my time being involved in the Mastodon project as an active developer.  They were written as a “personal history”, which is to say that they were a narrative chronology of developments from the standpoint of my own horizons of perception, and not necessarily a broad historical account.

A History:

Fringe Mastodev – Part I: The Beginnings

In Part I: The Beginnings, I describe the beginnings of CW‐discourse (which has existed for as long as CWs themselves) and its deployment as a weapon of racism against mastodon.socialʼs early marginalized, nonwhite users.  This event was the catalyst for the initial bifurcation of “flagship” (as mastodon.social was then known) into two, and then three, closely‐knit but nevertheless distinct communities—these new additions being awoo.space and icosahedron.website.  Discontent with how the event was handled radicalized a small segment of active users, myself included, into talks about how upstream and flagshipʼs present control of the Mastodon software might one day be usurped.

A History:

Fringe Mastodev – Part II: Enter Allie Hart

Part II: Enter Allie Hart describes the significant changes to the Mastodon platform which occurred after waves of new users started pouring in the following April.  This shift had both positive and negative results.  On the one hand, the fediverse grew much larger, and more diverse, than it had ever been; paradoxically, the development staff accordingly became more straight and normative, no longer depending on the support of Mastodonʼs initial queer base.  Although issues of race were what had initially triggered our discontent, the fact that most of these surviving radicals were white confused newcomers who—in some cases—saw our hesitations regarding these changes as a conservative reaction to Mastodonʼs growth.  (To paint it as one or the other is not necessarily fair.  Although myself, and the people I consulted with, had taken a firm stance against early racism on Mastodon, not everyone who jumped on board with our criticisms could necessarily vouch the same.)  This culminated in the publishing of my piece, Mourning Mastodon, and the departure of the core queer bloc from mastodon.social to places like witches.town (RIP).

A History:

Fringe Mastodev – Part III: Joining GlitchSoc

The end result of these conflicts is made clear in Part III: Joining GlitchSoc, which describes the founding of the GlitchSoc fork from the labour of this queer base.  As the first successful fork of Mastodon (there had been several others attempted prior), GlitchSoc is the first development project which might properly deserve the title of fringe Mastodev.  Not described in this post, several other instances at this time were also shipping their own, primarily æsthetic, improvements, such as the custom theming work done by witches.town and cybre.space.  The limited upstream support for instance CSS and themeing was to no small degree thanks to the contributions of the cybre.space admins.

A History:

Fringe Mastodev – Part IV: Intermission

The fourth, and ultimately (if unintended) final post in the series, Part IV: Intermission, takes a step back from the personal history and narrative that I had maintained thus far to critically examine the assumptions and power structures at play, analysing the way in which Mastodonʼs culture of entitlement manufactures, exploits, and ultimately debilitates caretakers working in its community.  Not the least of all because I decided to include my own personal encounters with these behaviours in the narrative, this post initiated no small amount of drama and discourse, a minority of which was actually on‐topic—not in my own mentions and feeds (which I would have welcomed, actually) but in those of my friends (which I took very personally).

Not that dogpiling would normally be enough to get me to shut up, this discourse was a catalyst in the sense that I found I had zero need or incentive to continue working to theorize and build a Mastodon which had historically attacked and driven away people of colour, repeatedly exploited and abused myself and my friends, and which lacked the respect for boundaries and personal space to discuss the issues I was trying to broach in a caring and constructive manner.  So, I stopped.  I took a break from writing criticism in general until the launching of this Journal, and from writing on the subject of Mastodon in particular until this post, nearly a year later.

Thankfully (for Mastodon, and myself), even as I left the stage, others pushed forward with the fringe Mastodev agenda.  Most notable among these is Darius Kazemi, who has developed and expanded upon my original thesis in an encouraging (and ultimately ((although to what extent being a well‐known and male‐passing internet personality and (now ex–)Mozilla fellow has helped him in this is anyoneʼs guess)) more effective) way through his guide, Run your own social, and accompanying fork, Hometown.  At the same time, others have, and with far fewer words, been making their own contributions to the fringe Mastodon ecosystem, through instance‐centred forks such as Monsterpit, Computer Fairies, sleeping.town, and many others.

Run your own social How to run a small social network site for your friends

by Darius Kazemi,

While these forks have provided us with new features, and while Dariusʼs work has given us a usefully optimistic (if idealistic) roadmap to work from, there remains (as ever) a lack of critical analysis of what the shape of power might look like in this new world.  And so (as the only person on Mastodon who ever seems to bother writing about these questions), I have resigned to apply myself to the task once again, and with this post begin to sketch out some rough lines regarding what we might expect—or work towards—in the future.

Open‐Source Labour

In order to talk about power structures in a world of forks and fringe developers, we need to first analyse the shape of power inherent in the processes of forking, and the open‐source model, themselves.  The latter, especially, has received a fair amount of coverage lately (and not‐lately), as people have slowly gleaned onto the fact that even Codes of Conduct cannot save you when your project already has assholes and abusers in control.  As far as open‐source developers go (low bar), Eugen Rochko is (to my knowledge) a little self‐aggrandizing, but otherwise pretty alright.  At the same time, Mastodonʼs development team remains relatively untested as far as its ability to handle internal abuse, and Iʼm not particularly enthusiastic about its chances.

The blatant sheltering of abusers aside, the problems with contemporary open‐source development boil largely down to questions of access and labour.  In the contemporary, monolithic model of large canonical upstream projects, the former issue is most relevant, as the scope of labour is restricted by which developers and what sorts of work have a hope of acceptance (and, indeed, presence) within the upstream community.  This was the problem of early Mastodon, as I addressed in Mourning Mastodon and as others have commented since.  Wxcaféʼs When a toy isn't a toy anymore provides an excellent depiction of the broad affective narrative which tends to accompany and shape these proceedings.

When a toy isn't a toy anymore

Posted by Wxcafé on

Discontent with this status quo has led some developers to abandon the (so‐called) “open source community” altogether; see, for example, the remarks by blogger rachelbythebay, whose response to turmoil in the Linux community was as so:

My response to this is to say “wow, look at how screwed up these communities are”, and then tag on “just like I always suspected”, and then finally I add “and that reinforces my decision to stay out of them”.

[…]

[…] Grab it, fork it locally, fix it locally, and share fixes with a few trusted individuals who have been invited to participate in the system.

Does this help the community?  Nope.  Wasted effort abounds.

The centralization of contemporary open‐source projects comes as a direct consequence of capitalistic maximal‐output/minimal‐labour optimization practices—which, due to techʼs massive diversity and accessibility problems, donʼt even work—but, if they did, would remain far from proven as the philosophical standard to which all software development should conform.  “Wasted effort”, in the form of private forks, incompatible changes, and simply not bothering to submit a pull request upstream, is slowly emerging as not only a valid use of development time, but an organizing force from which one can structure a small, decentralized, privately‐run software community.

Although their existence as AGPL social‐media server software prevents them from ever beïng truly private, the fringe development scene on Mastodon follows this trend, and has been the dominant force by which external development has taken place on the network since mid‐to‐late 2017.  Instead of petitioning upstream for new features (as was the dominant paradigm previously), individuals on the fediverse can now directly petition their admins to incorporate patches from other servers, or do development work of their own.  And since these changes immediately benefit (and satisfy) the people who requested them, there is not necessarily a strong impetus to push for their adoption across the broader network.

Mastodon is crumbling—and many blame its creator

Ana Valens —

This shift has become so absolute that critiques of the development practices of upstream Mastodon as inhibiting the potential of the software, which were once so widely acknowledged and circulated, now appear painfully retrograde.  Ana Valensʼs 2019 Daily Dot article, Mastodon is crumbling—and many blame its creator was—to a significant degree—a popular retelling of my arguments from Mourning Mastodon; far from the acceptance of the original, however, its reception among queer communities on the fediverse was rather tepid (at best; the article was the subject of extreme ridicule in some fediverse circles.  Part of the problem here—I believe—was the articleʼs reliance on quotations from others and its general unwillingness to come down with any strong statement of its own, concluding, essentially, “time will tell”.  My advice for people covering the fediverse?  If you are here, if you have an account and are present in our culture, you are your own best source.  As a reporter on the ground, you do not need to rely on the words of others to make your points, and you cannot claim ((especially if you are a part of the queer community whose points you are covering)) impartiality regarding the issues.  Put yourself in the narrative.  The best, and most widely‐lauded, publications regarding Mastodon have all done this.).  The thesis of Mourning Mastodon was not that the fediverse of old was crumbling, it was that it had died; what I did (and could) not know at the time was that the political structures which had constrained development up until that point would largely die along with it.

But the fact that upstream no longer holds a monopoly on Mastodon development has not erased power from the equation—and most people seem to understand this.  However, the popular analysis of the situation tends to miss the mark.  The dominant assumption seems to be that power on this new fediverse rests in the hands of those with extensive development backgrounds, who can found the instances they want and make changes as they see fit.  To the contrary, it is my experience that those with extensive preëxisting privilege and development expertise are typically content with the traditional model of upstream contribution, and it is instead Mastodonʼs most marginalized and imperilled users who exert the greatest amount of effort to first learn, and then develop, fringe Mastodon software.  The reasons for this are twofold:

  1. For those with experience moving in open‐source circles and whose interests align with upstream development, a far greater splash can be made simply by contributing upstream, and

  2. Drawing from page 06 of this Journal, manufactured need and toxicity can be a form of labour extraction, in which the survival work of queer bodies falls to, as I stated in Fringe Mastodev – Part IV : Intermission, those who either canʼt afford to let it slip—the most marginalized—or those who arenʼt willing to—frequently because they are survivors of great moments of need themselves.

Just because marginalized and imperilled users are the ones developing fringe Mastodon software does not mean they are the ones in power, however—and I have gone into this subject in more depth already in page 06 § 02 “Queer Labour”.  In the specific case of Mastodon, its open‐source, AGPL nature means that it is a simple matter for privileged developers to take the labours of minority and fringe elements and incorporate them into upstream.  Not fixing issues that queer users find particularly relevant may well become a viable strategy for getting them to do the labour at no cost themselves.

So the divide on Mastodon is not, as it is often presumed, between developers and non‐developers, or between admins and ordinary users.  It is, as it has always ever been, between those with need, who labour with little choice, and those with privilege, who are able to passively profit.(And less this read as a direct criticism of Eugen himself—he actually is a labourer whose income depends on his developing features, albeit about as privileged a fediverse labourer as one can find.  This criticism falls even more heavily on the other privileged folks on the fediverse, who also benefit, and donʼt have to lift a finger in work.)  And this is a reflection of broader trends in culture more generally, of relying upon and subsuming fringe culture for the benefit of upholding privileged norms.

Despite its current characterization within the fediverse as a progressive and potentially‐radical alternative to existing tech norms, the Hometown fork and Run your own social movement itself engages in this, having achieved quite a bit of notability (appearances in conferences, Marketplace, etc.) incorporating an idea and ethic (local‐only posting, first developed for GlitchSoc) originally created with trans labour as part of an (at the time) trans‐run Mastodon fork.  This appropriation, sanitization, and erasure of marginalized labour through “for‐everybody” marketing is not a fault of Hometown in particular, but rather inherent in the open‐source model, where recognition and benefits accumulate around software projects, divorced from the contexts of the individuals or communities which produced them.

(And thank god we can all use Linux without thinking of Linus!  —Or is the fact that we can all use Linux without thinking of Linus the reason that he is still the kernelʼs maintainer?)

Contradictions

So far, nothing new.  The arguments presented above have been true for open‐source software since its inception, and the situation of fringe development offers us nothing in particular to directly combat them.  But suppose we borrow a leaflet from Dariusʼs handbook and ignore, for a moment, the argument at scale?  That is, the appropriation and profit off of marginalized labour done by upstream and Mastodon at large is surely unjust and reïnforces the privileged comfort of its least‐marginalized users.  But, at the same time, it poses no special immediate threat, is indeed no different than the problems that marginalized people have been dealing with in tech for decades, and the possibility remains that, by building communities of strength and support at a smaller scale, we can perhaps eventually form a network of solidarity of a sort which will upend and/or supplant this established order in its entirety, without need for ever going toe‐to‐toe.

Unfortunately (or else there would be no reason in writing this post) we are still largely at a loss for what this network of solidarity might ultimately look like.  Far from posing conclusive answers, I am presently most interested in challenging some of the assumptions which I believe limit our perspective when it comes to this task of building.  In particular, I am interested in untangling the inherent contradictions between an approach which valorizes local solutions that need not work for everyone, and a federation whose protocol (as currently implemented) hinges upon the idea that a post originating on one server necessarily need be transparent to any other.

This latter point is something which remains largely uninterrogated (and, indeed, romanticized) in Dariusʼs work; small federated social networks, he claims, are good precisely because they are still transparent to passersby and can still communicate with anyone, from anywhere.

You might ask: how can one small computer replace something as huge as Facebook in my life? Well, the reason is that you control this one computer for your site, and then that computer talks to thousands of other computers, which gives you access to literally millions of people and organizations and videos and all sorts of other things.

But is having access, and being accessible, to literally millions of people and organizations and videos and all sorts of other things always a good thing?

This was a rhetorical question; it obviously is not.  It is 2019, and we know this now.

To both their credit, Eugenʼs original innovation of per‐post privacy settings for Mastodon in late 2016, and GlitchSocʼs development of local‐only posts (later adopted by Hometown) in 2017 have, in minor ways, subverted this idea of universal visibility.  However, the revolutionary potential of these features is diminished in the fact that they still cling to an overall sense of universal encodability—that is, that there can/should/does be an unproblematic standard encoding form which can be used to represent knowledge (in general) and individuals (in particular).  This universal encodability is built upon a set of assumptions (all accounts must have exactly one as:preferredUsername which is an xsd:string—not multiple foaf:nicks or an integral mon:trainerID.  All dates must be Gregorian—not Hijri, Hebrew, or Indian—and their days measured in seconds—not .beats.  All post content must be HTML; it must be in a Unicode script; it must be in a language registered according to the practices outlined in BCP47.) which together form a normative model for what human social life, and social interaction, can and should look like.

In other words, although posts on Mastodon are not literally accessible to anyone, they are still imagined as if they were—this imagined “anyone” inheriting all the normative (colonizing, white) assumptions of the tech industry more broadly.  And this imaginary of a universal, collapsed global context stands in direct contradiction with the sorts of small, unscalable, community‐focused interactions that manifestos like Run your own social claim to support.  On the one hand, these structures perform a normative erasure which limits the kinds of identities, relationships, interactions, and discourses which can take place.  On another, the presence of an imagined global social encourages a context collapse towards normativity even in cases (such as local‐only or private posts) where the actual audience of a post is well‐defined.  This is to say, the emphasis on “visibility” made by upstream and Run your own social as the basis for social differentiation presumes a knowable liberal subject who is able to fluidly navigate the fediverseʼs public, local, and private spaces.  And, the fact that participants in the fediverse are mandated to encode themselves within a single normative structure makes their work ripe for appropriation, yet another manifestation of the same cultural impulse to view, incorporate, and ultimately profit off of marginalized bodies, and their labour, which we have seen in the relationships between the various fork projects themselves.

For a tech‐oriented reader used to universal standards with emphases on cross‐compatibility and global interconnection, this might sound like it is coming from completely beyond the pale.  So I would like to jump backwards a decade and a half, to talk about Linked Data, and Mastodonʼs first predecessor, a little thing called FOAF.

Divergent Ontologies

As a brief definition of terms: Linked Data is the conceptual framework used by ActivityPub, Mastodonʼs federation protocol, and it has a long history of being used for social media and social networking purposes.  It is built upon a knowledge framework and set of related technologies known as the Resource Description Framework, or RDF.  Central to the Linked Data and RDF model is the idea of ontology, which is, broadly speaking, a relational vocabulary of terms which may be used to describe things within a given universe of discourse.  The ontology of ActivityPub (and Mastodon) is the Activity Vocabulary.  Earlier versions of Mastodon, which used the OStatus protocol, used a number of different ontologies, including one known as Portable Contacts.  Preceding both of these vocabularies came FOAF.

FOAF has been evolving gradually since its creation in mid‐2000.  There is now a stable core of classes and properties that will not be changed, beyond modest adjustments to their documentation to track implementation feedback and emerging best practices.  New terms may be added at any time (as with a natural‐language dictionary), and consequently this specification is an evolving work.

[…]

It is important to understand that the FOAF vocabulary as specified in this document is not a standard in the sense of ISO Standardisation, or that associated with W3C Process.

FOAF differed from the ontologies defined by these later standards precisely in the fact that it wasnʼt a standard—it had no reference to RFC2119; it had no normative sections.  Its task was descriptive—like a dictionary, documenting a set of terms which had current usage in the FOAF universe—that is, with the people in the FOAF community who used them.  This idea of a “universe” or “community” is one of the most fundamental—and most ignored—aspects of Linked Data ontologies; ontologies can define the relations between terms, and how computers should process them, but the actual meanings of the terms themselves cannot be defined in code.

The earliest FOAF vocabulary was offered as a “utility vocabulary” within the RDFWeb project, and its documentation was heavily driven by implementation experiments.  In fact many of the spelling and stylistic inconsistencies in the names for FOAF terms came from the habit of testing things in real published RDF/XML files before documenting them in the central specification.  The FOAF spec was as a result always framed in the role of a dictionary, documenting the terms used in published FOAF files.  The vocabulary defined here was designed to serve a practical need: that of documenting work‐in‐progress vocabulary without confusing users and implying stability merely by some term appearing in the FOAF spec.

This contextual and contingent aspect of ontologies is illustrated by danah boyd in this wonderful anecdote from her book, Itʼs Complicated:

Much of what seems like inaccurate identity information is simply a misinterpretation of a particular act of self‐presentation.  This issue was particularly noticeable in early social media genres in which explicit identity information was required for participation.  Consider, for example, MySpace, which required a user to provide age, sex, location, and other fields to create a profile.

When I stumbled on Allieʼs MySpace profile, I learned from the demographic section that she is ninety‐five years old, from Christmas Island, and makes $250,000+ per year.  While it is possible that she is nearly a centenarian and logging onto MySpace from a remote, sparsely populated island in the Indian Ocean while running her highly profitable company, this seems unlikely.  A quick glance at the rest of Allieʼs profile reveals other information that suggests she is more likely to be a teenage girl attending high school in New Jersey.  […]

I met many teens who fabricated answers like name, location, age, and income to profile questions.  They thought it was amusing to indicate their relationship status on Facebook as “Itʼs Complicated” whether they were in a relationship or not.  A casual viewer scanning Facebook might conclude that an extraordinary number of teens are in same‐sex relationships because so many have chosen to list their best friend as the person that they are “In a Relationship” with.  In the same vein, Facebook profiles suggest that the US census data must be inaccurate because, at least on Facebook, teens often have dozens of siblings; of course, a little bit of prying makes it clear that these, too, are close friends.  These are but a few of the playful ways in which teens responded to social media sitesʼ requests for information by providing inaccurate information that actually contains meaningful signals about friendship and society.

[…]

One way of reading teensʼ profiles is to assume that they are lying.  But marking oneself as rich or from a foreign land is not about deception; itʼs a simple way to provide entertaining signals to friends while ignoring a siteʼs expectations.  Most teens arenʼt enacting an imagined identity in a virtual world.  Instead, theyʼre simply refusing to play by the rules of self‐presentation as defined by these sites.

In the anecdotes above, the age, sex, location, and other fields of MySpace and other sites form an ontology of sorts for social media profiles on their networks.  Allie and other teens meaningfully employ this ontology, but in a manner different than that intended by the sitesʼ authors.  They belong to different universes.  And this fact, and potential—that an ontology is meaningless without context—is why RDF and Linked Data was, until recently, largely deemed a failure outside of specialized, controlled communities (libraries, medicine) for its inability to scale.

So, ontologies are defined by their communities.  And FOAF was simply a written specification for the terms (and their meanings) commonly in‐use by the FOAF community.  If the community begun using new terms, or the same terms differently, (just like with any natural language) the specification would have to change as well.  If another community decided to start appropriating those terms for different purposes, or if the FOAF community itself split, new terms (and a new specification) would likely be needed in order to disambiguate the two.

This may sound unbearably messy!  ;But it is also the situation of discourse.  In the world of social media, the messiness of human communication is something one will have to deal with eventually, in one way or another.

There is no requirement that social profiles on the Semantic Web necessarily use the FOAF vocabulary, or all of it, and indeed other potential vocabularies are linked to from within the FOAF specification itself as related work.  A principal purpose of Semantic Web and Linked Data technologies like the Web Ontology Language (OWL) is precisely to describe relationships between those ontologies that different communities develop.  And so has happened, between ontologies like FOAF, Semantically Interlinked Online Communities (SIOC), Schema.org, and Dublin Core.

Compare the language above to ActivityStreamsʼs Activity Vocabulary, though:

This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation.  It is a stable document and may be used as reference material or cited from another document.  W3Cʼs role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment.  This enhances the functionality and interoperability of the Web.

[…]

The Activity Streams 2.0 Vocabulary defines a set of abstract types and properties that describe past, present and future Activities.  The vocabulary is defined in two parts:

  1. A Core set of properties describing the generalized structure of an Activity; and
  2. An Extended set of properties that cover specific types of Activities and Artifacts common to many social Web application systems.

While not all Activity Streams 2.0 implementations are expected to implement support for the Extended properties, all implementations MUST at least be capable of serializing and deserializing the Extended properties in accordance with the Activity Streams 2.0 Core Syntax.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", " SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

Far from taking a descriptive, dictionary‐like role, the Activity Vocabulary, ActivityStreams, and ActivityPub make it their goal to create a normative, prescriptive, and universal social media vocabulary with widespread deployment.  Their language is dry and precise, with an emphasis on interoperability of implementation over diversification of use.

My purpose in comparing the two specifications is to demonstrate the fact that rigid, interoperable vocabularies are an intentional choice, not a technological necessity or a philosophical requirement.  It is, in contemporary, Web‐based tech, largely an uninterrogated choice, but this has not always been the case.  Particularly, in the case of ActivityStreams and the Activity Vocabulary, this approach was likely informed by its imagined utility; from the joint press release announcing the chartering of the Social Web Working Group which developed the specification:

Businesses are turning increasingly to social applications, and a recent study confirms that businesses that embrace social tools to share knowledge internally, collaborate with suppliers, and listen to their customers experience much greater growth than those that do not.  In a modern organization that has diverse IT systems, BYOD policies, remote workers, and regional partnerships, crucial information about business process status can be lost in email or when different systems do not interoperate.  Open standards are the key to scalable integration.

It hurts businesses if their employees or customers are posting social media in a format which they cannot interoperate with.  What is the reason for the shift from casual, descriptive, community‐oriented ontologies to formal, universalizing, and normativizing ones?

Open standards are the key to scalable integration.  In other words: Normativity scales.

Conclusion

If we are to make good on the potential of fringe development and community‐focused, nonscalable software, we need to break away from the idea of normative, universally‐understood ontologies.  This does not mean we need to break away from Linked Data, or even ActivityPub.  Indeed, I am passionate about ActivityPub and Linked Data as technologies precisely because of their extensibility, their ability to simultaneously and in various ways support differing, and frequently not mutually‐intelligible, ontologies and methods of representing the world.

This is the unrealized promise that the Web has always offered, and it is the next big challenge for the fediverse to tackle.

However, in setting our sights on this goal, we have perhaps let ourselves slip into idealism yet again.  Even if the proliferation of non‐normative vocabularies, alongside community‐oriented technologies of non‐scale, is the magical panacæa to Mastodonʼs long patterns of assimilation and exploitation, there are at least three problems which remain unaddressed that barrier our ability to reach that point.

First:  Who will build it?Again, this task will likely fall to the most marginalized, seeing as the existing lingua franca of the fediverse is that of enshrined normativity, and those who benefit from it will have little need or impetus for change.  Paradoxically, these workers will need to be fluent in and communicate through the existing normative fediverse systems in order to coördinate their efforts in this matter.  There are no easy solutions to this problem; it is the work cut out for us.

Second:  Who will control it ?  So long as the GNU AGPL license applies to any and all fediverse software, it will perpetually be possible for those in privilege to take ownership of, and redirect or control, software features as they appear.  As important as open source may be—from both ethical and pedagogical standpoints—it may be necessary for communities to begin developing software packages which do not immediately belong to a single white‑ and cis‐dominated public commons.

And finally:  What of the power differential which results from these imbalances, and which has resulted from years of passive cis/white profit off of marginalized labour ?  While carving out our own spaces is useful, it does woefully little to take power back.  Indeed, this is not a problem which can be solved through developing communications technologies alone.

Nevertheless:  I feel that continued pursuit in this direction is a necessary step for the fediverse to take, if only because the current situation is likely untenable.  At the time of writing my first commentaries on Mastodon, I could not have imagined the diverse sites of community involvement which are taking shape on the platform today.  It is my hope that if we continue this work with an eye to the above questions, new horizons will open up which will give us additional insight into the necessary steps for a just future.