Half an Hour,
Feb 11, 2021
I'm going to take Daniel Goldsmith's excellent post Praxis and the Indieweb as a point of departure for this post. Like Goldsmith, I am a fan of the Indieweb, or at least, the concept of the Indieweb. And I've been involved, at least around the periphery, in its development for many years.
In what follows I will not only talk about the Indieweb, I'll also talk about some of my own projects. I want to be clear at the outset that when I talk about my own projects, the intent is to offer an example of some alternative points of view. I have no doubt that there are numerous other such examples.
What is the Indieweb?
Before jumping in, though, I want to take a moment to ask, what is the Indieweb? Part of it is about ownership: as the Indieweb web site says, "When you post something on the web, it should belong to you, not a corporation." And part of it is about control: "You can post anything you want, in any format you want, with no one monitoring you."
In practice, though, there's a lot of slippage around those ideals. Nobody owns their entire website; the servers it runs on, the domain name, the software it uses, the protocols it follows, even the content it publishes - all of these may be owned by someone else, and through some combination of payment and licensing we make use of these things, adding just enough of ourselves to make it 'our own'.
And nobody does anything online without being monitored (indeed, there wouldn't be any point; it is after all a communications medium). There is at once the all-seeing eye of Google, law enforcement and security agencies, our service providers watching traffic, various copyright and monitoring services, and finally, our own readers, of which we hope to have at least a few.
Given this, there is I think a spirit of what counts as the Indieweb, which may be characterized as do-it-yourself. And this do-it-yourself spirit, I think, is very much in a tension with other values and ideals. Because while we can do it ourselves, I don't think most people really want to, and certainly almost nobody has the time. That's why we end up in places like Twitter and Facebook.
And it is the Indieweb's characterization of these websites as silos that points to a fourth major aspect of the Indieweb: inter-connectivity. At least a part of the Indieweb proposes that anybody should be able to communicate with anybody, without being subject to subscription barriers, algorithms, advertising and content placement, technical limitations, and terms of service.
Who is it For?
This leads us to the first of Goldsmith's criticisms: "the movement as it is currently structured can never move into widespread acceptance, that it is both target blind and exclusionary."
One would think that the Indieweb is targeted toward people who want to own their own website and content, to control that site, to build it according to their own needs and ideas, and to be able to participate in an open network of similar sites. Something like that.
But the Indieweb is target blind, says Goldsmith, in the sense that it seems to be aimed toward people who don't really want to leave existing social networks, and want specifically to emulate the function of the social networks without being limited by, say, their moderation policies.
There are two ways this is the case. One is the design of the Indieweb itself, which is centered around types of posts, all of which are basically copies of the types of posts on traditional social network sites. The other is in the concept of POSSE - Publish Own Site, Syndicate Elsewhere.The idea is that you create content on your site and then broadcast it into traditional social media sites - whereupon, writes Goldsmith, your rights of ownership end.
Ironically, I think that both of these elements were designed in an effort to make the Indieweb more popular and accessible to a wider audience, since it emulates form factors users already understand, and it doesn't require a complete break from traditional social networking sites. But there are differences between these being features of the Indieweb, and these being part of the core design.
The Indieweb has been designed for a specific type of user, one who wants to build and run their own social networking website in such a way that it is interoperable with existing social networking sites (and maybe, with other Indieweb social networking sites). That's why it focuses on posts, and that's why it is based on POSSE.
Posts
Don't get me wrong. I love posts. I've written 33,692 of them, most short, some long like this one. I've worked with various types of posts over the years and settled into a few basic types: links, articles, comments, announcements.
But my work has differed from Indieweb on two fronts. First, in my own software, there's no limit or standard definition of a post you must follow. One of my types, 'link', is illustrative of that. Back at the beginning of blogging, a post used to be about something, usually an article of some sort written by someone else. So the post would include data about this article: who wrote it, what it's URL was, what website it was on, maybe a short description. This is the post as bookmark example, and I've never strayed from that, and have always called this a 'link post'.
The link post is not even in Indieweb's canonical list of post types. Instead, at the beginning of blogging, another model was adopted by the (then) startup blog companies, and these were more in the model of personal diary entries. So there would be no URL other than the post's own URL, and no website other than the one it was on. This model became the Blogger model and the WordPress model and was carried over into things like Twitter and Facebook and the rest.
This model also carried over into things like interoperability standards. Although RSS was originally designed for bookmarks, building on Netscape's bookmarks feature, it was eventually transformed into a model for self-syndication, and only ever used to describe one's own work. That's why the 'pieces of a post' section on the Indieweb web site never goes beyond basic self-centered features like URL, contents, date, etc.
All of this is OK. There's no requirement that people create link posts just because I've created more than 30,000 of them. There's no requirement that websites be outward-looking, like mine, rather than inward-looking, like most others. But these should be options, rather than The Way It Is Done.
That's why, in my own software, gRSShopper, I've designed posts so that people can create whatever post type they want, and add whatever properties they want, and have this structure propagate into the post metadata (like RSS and JSON). And that decision will have a significant impact, as we'll see later on.
 |
| Screen shot from gRSShopper |
On the second front, I have never felt limited to posts. In fact, I have always been frustrated by the standard ontology of the technorati. On gRSShopper I have a large and open-ended ontology that includes publications, presentations, events, media, courses, projects, whatever (see the illustration). You can make any data type, populate it with any fields you want, and link different types of entities with each other however you want in a graph (to be clear, though: it's not a graph database; it's list an open-ended set of linked data types).
What Is the Web?
Now I've heard the objection many times: if you let people defined data types however they want, then their sites will be incompatible with each other. If you want everybody to be able to communicate with everybody, they have to use the same fields in the same way.
My response is: that's false, because I've been doing it differently for decades, and people can still communicate with me (and I with them). It becomes an issue only if you're thinking of the Indieweb (and the web in general) as a broadcast medium, where you want your thoughts and ideas and posts to propagate as far as possible and to as many different platforms as possible. Then you need global standardization.
But I've never thought of that as the design prin
ciple for the web, and I've never thought of that as a core principle of the Indieweb, or of the web generally.
Broadcasting came late to the web, and didn't really appear until the web was commercialized in the late 90s. Before then, it was genuinely a communications medium, characterized by person-to-person or smallish group communications. The idea of blasting a message to everyone on the web, or even everyone on a single network, was thought of as selfish and excessive, and to be reserved only for the unusual and important.
The commercial web brought with it context collapse, in which everybody is talking to everybody. This is what creates the need for filters and algorithms and moderation and all the things we said above that the Indieweb is trying to avoid. But when everybody talks to everybody, these are unavoidable. They have to be managed somehow, and sometimes it feels like most Indieweb projects are exercises in different ways of doing this.
My own view of the Indieweb (and again, not everyone has to share this view; it's OK) is that it's a space for conversation rather than syndication. Of sure, we still use syndication technologies, but we're not locked into the broadcast model, we can design our own syndication formats, use our own classes and entities, and be able to focus in ways that a broadcast medium cannot.
A system based on webs, in other words, and not on stars.
 |
|
| Web (left) vs Stars (right) |
I've written about this before. But at that moment in history - 2006ish - the prevailing sentiment seemed to be that a power law distribution of influence was normal, that there would be outsized voices in the blogosphere, and that the specifications should be designed to make this possible. Fifteen years later and the same model - the same people, even - continue to prevail. And that's what gives us this social network model of the Indieweb.
Who is the Indieweb
To this point we have been addressing the criticism that the Indieweb is target blind. We now turn to the criticism that it is exclusionary, or as Goldsmith describes it, "one of the most glaring problems of the indieweb movement: the 'Single Point of Aaron'."
The Aaron in this case is Aaron Parecki. Most Indieweb technologies, Goldsmith writes, are Parecki technologies. "Webmentions.io, for instance, that's an Aaron Parecki site. Aperture, the microsub reader... that's also Aaron's. The Microsub specification is written by Aaron, much as the Webmention spec was.... (and) is one of the authors of the Oauth." Some of the core figures also include Tantek Çelik , formerly of Technorati, who created microformats, and Ryan Barrett, who worked for Google.
Goldsmith characterizes the Indieweb crowd as "with a few notable exceptions, the indieweb is almost entirely white, male and north american." That may be, but I think it's too broad a characterization to be useful. My observation is that in one way or another they all come from what I have called 'the Nexus' - that is, the Berkeley - Stanford - Harvard - MIT Nexus. The same place Google comes from, that Facebook comes from, and that a certain view of the world comes from.
As I mentioned above, it's a view of the world that sees broadcasting, power laws and stars as normal and inevitable. Even more, it's a view that entrenches the idea of winners and losers, views the commodification and often the commercialization of community and media as inevitable, that views all of this as being inherently individual-based, libertarian, and 'free' in a very special and privileged sense of free.
It's also a perspective rooted in what has been called the meritocracy, the view that people get the wealth and recognition they merit, a view that those who make the tools make the rules, and that the people who are 'elite' are such because they deserve to be. And those people are, overwhelmingly, themselves. It has nothing to do with being male, North American or white, though for various reasons that's where privilege has accumulated in the past.
And though there is in fact a world-wide community of people working on this stuff, they view themselves as the (natural-born) leaders and inventors. They are nothing of the kind, of course.
First Generation
In recognition of something like this, Goldsmith takes aim and the Indieweb's characterization of 'first generation' Indiewebbers. Here it is:
Capable of building a CMS, custom blogging software, understands SSL, git, SSH, APIs, domain registrars, DNS, nameservers, communicating over IRC, and editing wikis, and is comfortable running a server to host their own content, and knows at least one basic web-based programming language. Comfortable with lengthy documentation.
Goldsmith notes, "I can do much, but not all, of the above, and I can do a fair number of things not on that list. I can still barely function in the Indieweb as it is presently formulated." I can do all of the things on the list and can also barely function on the Indieweb. And Goldsmith is quite right when he writes,
There is a complete dearth of simple, essential programs/tutorials/guides to accomplishing the basic tasks of the Indieweb. The movement is built around what was once called "dogfooding", but is now Eat What You Cook, creating the tools to make it work yourself, and using it. In this, it shares some features with FLOSS generally, the cult of the individual programmer.
The very existence of a term such as 'dogfooding' in core Indieweb documentation should serve as a red flag for anyone looking for an open and welcoming environment.
There are scarcely any examples of moving past self-sufficiency, providing scraps from the table for people to use. There should, at a minimum, be clear and established routes to achieving the goals of the indieweb ideal, presented in as clear and unambiguous format as possible, in a wide range of programming languages. Currently, that simply does not exist.
Quite right.
As it stands, the Generations diagram is wholly exclusionary. While it allows for people of less facility in computers to play a role in the movement, eventually, it affords little or no understanding of who those people will be. In short, it doesn't describe people in the "real world" (what on earth is Softalicious?) nor does it encompass people of lesser means.
These are not the values of a movement that looks outward. It is what we would expect from a movement that centers its own members as the stars, with no real need to consider the needs and interests of a wider community (a community that, for all intents and purposes, barely exists when viewed from the centre).
Rather than being focused on the technical prowess of a 'founding' generation, it should be focused on (shall we say) a road map of widely available applications and services that everyone can use without requiring a degree in computer science or eschatology.
What does that look like? Well, I tried to provide an example last week with Remote Comments. It would be a way of enabling people to very easily add a comment to a document without worrying about all the trappings of WebMentions and the rest; these would work behind the surface and be a part of whatever blogging or writing application they're using.
Exclusionary
The Indieweb is based on owning your own domain name and owning and managing your own web server. As Goldsmith notes, none of these is free, and in fact, they create a significant barrier to participation. "If a movement has at its core a significant barrier to entry, then it is always exclusionary. While we've already seen that the movement has barriers at ability and personality, it is also true that, as of 2021, there is a significant barrier in terms of monetary resources."
One of the things I really appreciate about Reclaim is that it costs significantly less than similar services running on, say, Amazon Web Services. Yet at the same time, I recognize that even this cost is a barrier to many people around the world, and that "If your liberation movement has an entry fee, then its just another country club." And there does appear to be an expectation in Indieweb that to be a player you're going to have to pay the significant up-front costs.
And that's the other thing I appreciate about Reclaim: they've made efforts to find ways to have other people pay for those costs. The Domain of One's Own program, for example, typically rolls out in such a way that the educational institution provides the hosting and peripheral costs, allowing individuals to freely develop their own online environments. That's how the first websites (back in the Golden Days of Personal Websites of the 80s and 90s) were made possible. No individual was setting up a web server; it was all enabled through institutions.
In more recent years, institutions have retreated from this role and handed it over to the commercial sector. Many of these commercial sector providers are spin-offs from the original institutional hosting program (or, as in the case of Facebook and Google, things done with institutional hosting). It's hard to see how anything like a genuine Indieweb can develop while the infrastructure remains almost entirely in commercial hands.
Of course, access to the internet itself, much less a space for one's own domain, is not evenly distributed. It's a free perk for those fortunate enough to be able to pay tuition fees, but for the large majority of the population, the only domain they can afford is a free (and easy-to-use) Facebook or Twitter address. With asymmetric bandwidth making it much harder to upload than download, people cannot easily host their own servers (and it's not exactly like internet providers, who also market broadcast content, want to make that any easier).
That said, if we really wanted a broadly inclusive Indieweb, we'd be talking not about how to set up large complicated servers, or offering additional platforms to sign up for and pay for, but rather we'd be talking about how to make self-hosting more accessible and available to individuals.
To me, right now, the only game in town seems to be self-hosted containers running pre-configured platforms accessing cheap (or free!) cloud storage space. I think this should be considered an essential social service. I think this is where people should be able to store their data - not just their 'posts' but all their data - their health and education records (maybe like Opal), their voting and policy preferences, their virtual environments and in-game characters, etc.
A Roadmap?
What would a roadmap look like?
I think we have to return to what we think the Indieweb is. The original goals were ownership, control, do-it-yourself, and inter-connectivity. These have morphed into some sort of amalgam of code camps and self-authored software. But I think that if we revisit these in the spirit of social and community benefit, we can envision something more encompassing.
An Indieweb is a...
- way for people to store and manage their own data (where 'data' means any digital creation or record, including metadata)
- a way for people to share data with each other without being required to give up their rights or ownership over that data,
- a way for data management and sharing to be independent of the particular platform they are using,
- a way for people to create common resources and services around that data, or in other words, to create interdependent communities,
- and an environment that is broadly egalitarian, based on the principles of a web rather than on mass and centralization, based on interaction rather than broadcasting.
I think that in addition to these basic descriptions of an Indieweb, there ought to be some desiderata describing what sort of technology meets this description.
For example (and I don't mean this list to be exhaustive):
- data specifications should be open, not only in the sense that anyone can use them, but also in the sense that people can add to them, adapt them, or choose which parts to use. Specifications, in other words, should be protocols, not standards.
- tools should be in the first instance simple and easy to use. Something should notbe counted as being 'a part of the Indieweb' if it requires special skills to operate. They should be cross-platform and (as Goldsmith says) supported in multiple programming languages.
- the tools should also be lightweight. Obviously this is a moving target, but they should ideally be able to run on a computer available to everybody - it should be possible to make them work (say) with a Raspberry Pi and a TV.
- the parts that depend on cloud services should be accessible to everyone, not just a subclass of people (like university students or company employees), and these parts should be (ideally) free or incredibly inexpensive, and generally regarded as essential infrastructure
- you shouldn't have to pay for it. You should be able to run the whole thing off your own computer if you want, without having to pay hosting costs to some online service, and you should be able to do so with a minimum of installation and configuration
I know that my own work is a long way from this. But it at least points me in a direction where there might be something worthwhile at the other end.
Mentions
- Praxis And The Indieweb, Feb 11, 2021, - IndieWeb, Feb 11, 2021
, - posts - IndieWeb, Feb 11, 2021
, - POSSE - IndieWeb, Feb 23, 2022
, - , Feb 11, 2021
, - , Feb 12, 2021
, - , Feb 11, 2021
, - Stephen's Web ~ Community Blogging ~ Stephen Downes, Feb 11, 2021
, - Aaron Parecki, Feb 11, 2021
, - , Feb 11, 2021
, - Aperture, Feb 11, 2021
, - Microsub-spec - IndieWeb, Feb 11, 2021
, - Webmention, Feb 11, 2021
, - Tantek Çelik, Feb 11, 2021
, - , Feb 11, 2021
, - The myth of meritocracy: who really gets what they deserve? | Class issues | The Guardian, Feb 11, 2021
, - generations - IndieWeb, Feb 11, 2021
, - eat what you cook - IndieWeb, Feb 11, 2021
, - The Original Sin of Free Software, Feb 11, 2021
, - Remote Comments, Feb 11, 2021
, - Reclaim Cloud – Reclaim Your Adventure!, Feb 11, 2021
, - Domain of One’s Own – Reclaim Hosting, Feb 11, 2021
, - Opal, Feb 11, 2021
, - On the Indieweb, Feb 12, 2021
