Platforms Suck

When the internet first started being a thing for the general population, it was met with great excitement about how it would democratize the distribution of information, both for publishers and consumers. In general this has been true, but in the earlier days, it was more true than it is today. Back then, if you wanted to publish online, you would find a way to host a website and publish through it. It was a site that you owned. The domain belonged to you, and the content was yours (for better or worse). Of course, there were problems with quality, security, and so on and so forth. In reality, the experience was frequently upsetting. Service software was often fragile and out of date. Infrastructure was unreliable.

It was in the context of this wild-west internet the “platforms” emerged. Within a few years, Facebook and YouTube both appeared (feasting on the corpse of MySpace and others, it must be admitted) to plow the way forward for the others that would come after (most notably Insta, Twitter, and TikTok). These solved the problems that people had with hosting their own sites by centralizing everything. The platform is now host, moderator, publisher, operations, infrastructure, and UX. This allowed them to create stable and reliable experiences with features that weren’t possible in the previous distributed mode.

It also had the end result of taking all control away from the people actually using it. You are no longer in control of your software, and it is frequently being used more and more to control you instead. This has several negative effects:

• The platforms have become the de facto moderators of public speech online. While it’s true this does not run afoul of the legal definition of the speech rights in many liberal democracies, it does collide in a very meaningful way with the spirit of those rights.
• Extremist content is often boosted due to the monetization models the platforms use. When brain time is the currency of the platform, they have an incentive to boost the “train wreck” variety of content, the kind that makes you feel threatened so you feel like you cannot look away.
• It alienates creators from their work and consumers by negotiating all interactions through the needs of the platform.
• Your data and time are easily exploited for things that don’t have any value to you (and are sometimes harmful).

Enter the Anti-Platform

In response to this, it would be prudent to create an anti-platform. A system that gives people an off ramp by giving them the ability to have many of the social interactions they want (and remove the ones they don’t) that is based on a distributed internet model.¹ A system that gives users complete control of their data not because of roles or permissions given by admins (and/or by using legislation to force platforms to give those), but by changing the structure of the social internet to put content creators and consumers at the nexus of control in the system.

The high level view of this structure has users running edge nodes that perform the information interactions needed to create the social web experience. The user then interacts with their node through an application that, in basic terms, provides an integrated feed reader and publishing UI. Ideally, this ecosystem would be built on existing open standards and integrated into existing projects as much as possible, with minimal extensions added to make the desired experience possible.

The Feed Reader

The feed reader app would be the primary point of contact point for the user. Its role is to aggregate all the information and behavior provided by the node’s services into a single user experience.

It would download the metadata about posts from a publisher that the node is subscribed to, and display that in a sane way. As the social connections between content would be stored in the metadata, the feed reader would be able to present the information in a way that takes that into account. An interface similar to Twitter or Reddit would be fairly easy to pull off.

Additionally, the user should be able to integrate their reader app with their publishing server to allow a seamless experience between reading and publishing as is currently the norm with social media systems. The publishing aspect of the reader should automatically add in the socially aware information to newly created content. For example, when adding a comment to some content that is being viewed in the reader, the publishing system would automatically set the field in the metadata that indicates what the comment relates to when publishing the comment.

The Node

In order to collect and present all this metadata to the reader, the user controls a node that runs a few services. For reading, the most important is a service that conforms to WebSubHub, which is used to subscribe to others’ feeds. I imagine that the feed metadata would be Atom with a socially aware extension, but other protocols could be supported.

For publishing, you’d need a fairly simple publishing server. Bog-standard blogging software with plugins to enable the socially aware features would probably suffice (well, and an API that allows the end user client to publish directly from there).

One thing the node would need is a way to authenticate readers, in order to allow publishers to whitelist content for certain people. For this, using 3^rd party identity providers that allow some kind of refreshable token authentication will be fine.

Optionally, the node could also be running Webmention. Webmention would make it possible for content creators to know when others are making references to their content. Everything would work without this particular functionality though, and some users may even prefer not to use it.²

Ecosystem

It would be possible for users of the nodes and readers I’ve described to be perfectly happy without anything else. They could self-host from their homes, and discover content using regular search engines or any of the other natural ways that content discovery happens. Because this is an open system, however, that allows the opportunity to create more ergonomic experiences for fun and for profit.

The first and most obvious of these is hosting providers. A lot of people won’t have the expertise or desire to self-host, which creates the opportunity for someone to become the WordPress.com of this thing. Key to this is that the user is still the location of power for their node. If it ever becomes a thing that the hosting provider is controlling user’s nodes, snooping on the data that goes through them, injecting ads, or using algorithms to filter content, then the whole thing is pointless. All of that doom and gloom being said, if that did happen, at least you’d have the self-hosting option to fall back on.

Another part of the ecosystem that I can imagine is something I’m calling a library. This is just the Apple Podcasts of social web feeds. Essentially, publishers would register their feeds with a library, and then readers could easily search for it there, making subscribing much easier. Rather than having hunt down feed URLs in the wild, the library would provide them directly with a pleasant user experience.

The last ecosystem concept I’ve come up with is what I’m calling a relay. All a relay is a service that will subscribe to your metadata feed and then publish it back out to people subscribed to the relay. The simplest version of a relay would just publish everything it subscribes to to all of its subscribers. Even this could be useful for people who want to quickly reach many users, or if the relay is managed for a specific purpose it could be used to create a “group” experience. A slightly more sophisticated implementation could allow for a Reddit-like experience, where you publish a post that is picked up by a relay and then it is forwarded on a particular subscription list (of which the relay has many).

User Story

It may be easier to imagine how this system would feel when fully implemented by imagining the following story.

The user wants to read socially informed content that their acquaintances have published online. To do this, they open up a local application on their computer (not a web app in this story, but there’s no reason a web app wouldn’t work). The application loads and connects to the node that they are running on a cloud hosting service. The node returns metadata about newly published content to the user, which shows up as content entries in the user’s feed.

Like many other social internet experiences, they can see information from the people that they are subscribed to. They see others’ posts, branching comment trees, reactions, etc. Each post in the feed is shown as a blurb of a few characters (similar to Twitter) after which the user must interact with the UI to expand larger content.

By default, the reader shows all content based on the time it was published, but the user has found that not everything from the feeds they’re subscribed to is relevant, so they turn on an AI that predicts the order that content should be presented in based on interest parameters that the user themselves has the ability to manipulate. The user sees what the AI thinks is most interesting, decides that it is wrong, and turns it off.

This is all done locally within the reader. The only time calls to the network are made is to get updated metadata, to load attachments (e.g. images / music / videos) for posts, and to expand longer content. That extra content is not stored on the user’s node, but only on the publisher’s.

The only information about other publisher’s content that the user stores is metadata. In that metadata are addresses for all the published content that the user sees, a short summary of the content (e.g. the first 255 characters), and the relationship of the content to other content. For example, if content is a regular post, it will have no special social relationship, but if it is a comment, reaction, or share, it will have a field in the metadata indicating the relationship of the content to the other content that it is referencing (most easily by using URLs).

The user notices that they have a received a request from an acquaintance to be added as a trusted reader for content that is only intended for specific people rather than being openly published. The user accepts the request by allowing the acquaintance to have special reader permissions for the user’s node and adding them to a specific reader whitelist.

The user decides that they want to write a comment on some content one of their friend’s shared. The application seamlessly provides an experience similar to what you’d find on any social platform, and then publishes the comment on the user’s node. While creating the comment, the user is able to choose which reading list they wish to publish their comment to, and only readers on that list will be notified about the new comment and be able to load it.

Pros and Cons

Pros:

• Moves the location of power to the creators and readers. This whole system could be self-hosted on a Raspberry Pi from your house. Or you could choose to have it hosted by a hosting provider. The beauty is that you get to choose.
• Infinite customization. Because the user is empowered by this system, they’re able to tweak it at any part of the stack.
• Content is hosted in only one place that the content publisher controls. This makes it possible to completely control who has access to it and get rid of it. It also means that the chain of responsibility is easy to follow. Is this the admin or the user’s problem? Well they’re the same person, so that’s easy to answer.
  
  This applies to meta-content as well as original posts. Comments and reactions are considered content the same as anything else, rather than extra data that hangs on to posts.
• You get branching comments for free! You don’t have to do anything special (well, you’ll want a reader that can display this in a sane way), and you can have infinitely branching conversations. This is a feature, and it is awesome.
• No overlords. All the profit, in whatever form that is, goes to you. If you wanna run ads, you get all the ad revenue. No algorithm will determine how ALL readers interact with your content (the reader itself will get to choose that). If it just makes you happy to connect with others, nobody is going to sipping bits of your brain-time for their own uses while you do that.

Cons:

• Technical knowledge. The user has to be at least aware enough to be able to say what they want in order to use this system. Hosting providers could do a lot of the grunt work, but the user still has to know what they want.
• I can’t think of a way to make developing this software profitable. I can think of ways to use it to make a profit, either as a creator or as a hosting provider, but actually making the software doesn’t seem very lucrative.

What About Activitypub (Mastodon)?

Activitypub is a protocol that allows the creation of federated microblog services. People can set up a service, gather users who publish there, and then federate content with other Activitypub instances. The most famous software that implements Activitypub is Mastodon.

It may seem that this concept and Activitypub are trying to accomplish similar things, getting rid of centralized platforms, and as such they may compete for attention. To that I say: why not both?

I suspect that in reality, after all is said and done, these user nodes will be completely cross compatible with Activitypub. They will essentially operate as an Activitypub peers that just happen to be more blog-like than the Mastodon experience.

That being said, I think there are a couple of advantages of this concept over Activitypub. The most important is that content is not hosted somewhere that the creator doesn’t control. Additionally, presentation to a reader is also in complete control of the reader. Activitypub is somewhat better than centralized platforms, but at the end of the day they are still a collection of many small platforms operating together rather than a system that moves the nexus of power to the user / creator / reader. Unless I’ve completely misunderstood how Activitypub and Mastodon work. Feel free to tell me I’m wrong.

Another difference is that there is no limit on the kind of content that can be published. For Activitypub, it seems that most implementations focus on a microblogging experience. In my proposal, because only metadata is shared between nodes, and the actual content is not shared, creators are able to publish any kind of content so long as they can find a way to host it somewhere.

1 Using only regular internet protocols. None of that blockchain nonsense.

2 Getting information from only publishers you explicitly follow is a benefit in my opinion.