Month: December 2020

From the standardization of packets of information in Internet protocols to the radio buttons we click on in social media privacy settings, the insistence on standardized tools drives Internet communications technology. These protocols and technologies worship at the alter of “scalability.” Any networked software tool attempting to gain traction (that is, venture capital) must have a plan for scalability. It must be usable by individuals, small groups, and large groups without much customization. It must operate in some kind of standardized way.

Scalability and standardization have become entirely invisible and commonplace, so much so that it is now just common sense. Who would question standardized Internet protocols? Who would argue for “unscalable” software that is built for very specific purposes? This push to standardize means that networked environments are, in essence, always built for “someone else.” They are an attempt to be as generic as possible so as to be scalable. (This also means that they are aligned with whiteness and its desire to disappear, the subject of a future post.) And so this software is by definition “badly made.” For some, it is especially bad – what is an inconvenience for one community is openly hostile and dangerous to another. Sometimes it’s even worse than this, since a convenience for one group might be actively harmful to another. Consider the fact that Discord, the chat tool initially designed for gamers but now applied to a range of other communication situations, allows different group discussions (called “servers”) to generate invitation links so that others can be easily invited to the conversation. This same function, when used by groups who are targets of harassment, can serve as a backdoor for organized raids of abusers and harassers (this is something Greg Hennis and I wrote about for an edited collection called Digital Ethics). Invitations links circulate on message boards, and bad actors use them to coordinate raids and attacks. This is just one example of how a standardized set of tools is simultaneously built for everyone and no one.

Given that we appear to be mostly locked in to certain software environments (Facebook, Google, Amazon, Alibaba, etc.), what are our options for living within and with these ill-fitting tools and environments? Our best approach may be to seek out and learn from the practices of those who have long had to work against the grain to live in an ill-fitting world. We could refer to these practices as the building of “bespoke networks” within these ill-fitting, standardized environments. They offer a glimpse at how we can reimagine networked life on a broader scale. These bespoke networks/tools exist throughout the networked life, so my argument is not that we need to necessarily start from scratch to build an entirely “new” set of tools. Instead, we can turn to those who have worked to build tools and spaces that operate by different logics, logics that do not fit well in standardized networks. When such tools catch the eye of the standardized scalable Internet, they are too often misunderstood as “add-ons” for this environment. But not everything is an app or a plug-in, especially when the tools and methods in question have been built for specific communities and purposes.

Darius Kazemi’s take on this (mentioned in my previous post) is especially helpful:

Any time I propose a new piece of software to a group of software engineers I’m asked the same question: how will it scale? We are trained as a group to ask this question. I think it’s the software equivalent of in manufacturing when someone asks “What will it cost to produce?” Since the marginal cost of producing software is effectively zero, it’s the scale, the ability for the software to be used by millions or billions of people, that becomes the limiting factor that everyone brings up.

Imagine two different software developers. One person writes a piece of software that makes the lives of one million people slightly easier. Maybe it’s better routing for navigation software and it shaves 30 seconds off the commute of a million people. Another person writes a piece of software that only ten people ever use, but it tangibly changes their lives for the better in very material ways; maybe they learn a trade that becomes a career.

One of these outcomes is not necessarily better than the other, and yet due to myriad factors, only the software with a million users is likely to get funding from entities—whether the context is for profit or not for profit.

I’d like to advance the notion that software does not have to scale, and in fact software can be better if it is not built to scale. I hope some of the examples I’ve given above have illustrated what is possible when software is used by a small number of people instead of a large number of people.

This approach to software design can be generalized to the design and maintenance of social networks, and this is also what Darius argues in his “Run Your Own Social” project. A small network of people can gather together and determine how they want to connect to others or whether they want to connect to others. They can gather under the banner of unscalability.

I don’t know exactly what this project is, but I can start with some stories about how I started thinking about it.

I have arrived at a half-formed research question: What does a federated model of networks (social networks primarily, but perhaps other networks as well) offer? A federated social network (or “distributed social network”) is “an Internet social networking service that is decentralized and distributed across distinct providers.” In the simplest terms, instead of sending data through servers owned by Facebook or some other company, groups can run their own social networking servers. But it’s not just a collection of “silos” (or echo chambers, or filter bubbles), because each of these smaller networks can link to one another, should they choose to do so.

In general terms, I am interested in what this kind of model offers our current situations, digital and otherwise. However, I’m interested in federated networks not just as a niche, technical solution to social networking software, one that we can implement with software like Mastodon, but also as a theory for working through our existing network infrastructure. I want to argue two things at once: we should push toward more federated networks, and we participate in a number of them already. Group texts, for instance, are something like a federated network. While the data itself is housed somewhere on a corporate server, there is at least some control over who is part of the conversation and how that conversation might invite others in (or not). This is stretching the notion of federated networks, but I’m interested in what that stretching might achieve.

My first real exposure to federated networks came through Darius Kazemi’s project, “Run your own social: How to run a small social network site for your friends.” I’ll return to Darius’ work in future posts, since it continues to shape my thinking about federated networks. Briefly, Darius is interested in giving people the theoretical and technical tools for creating their own small social networking site, one that does not rely on large corporations for infrastructure and that also does not sell off data in a Faustian bargain. Darius’ key insight, as I see it, is that setting up such a network does not really mean being a technical wiz but is instead “social first and technical second.” You have to learn how to create a community that agrees on norms and a code of conduct, which is much harder than learning the technical intricacies of social networking software like Mastodon.

Soon after reading Darius’ essay, I invited him to run a “Run your own social” workshop at the R-CADE Symposium we host each year at DiSC. The pandemic meant that R-CADE was postponed, but the project stuck with me. I used some of its insights to build a small social networking site for a class I taught this past semester (more on that in future posts as well).

I am interested in how a federated model might present a middle way between massive, corporate, standardized networks like Facebook and the smaller networks that some worry will turn into “echo chambers.” Like others, I’m suspicious of the argument that echo chambers or filter bubbles are “the problem” to be solved. Instead, I think the bigger problem isn’t that we won’t connect to others who disagree but that we currently have few options for deliberating collectively about whether and how we connect to others. The value of a federated model is that it allows a smallish group to determine how they want to connect to one another and to other networks. Instead of kneeling at the alter of connectivity, insisting that it is good to connect with everyone always, the federated model calls for a community actually think through how connectivity would happen.

This project, whatever it is, will try to figure out what a federated model looks like, what its roots are, how we are already using it already (if at all), how we might use it in the future, and more.