For some time now, I’ve been musing on how to move fediverse platforms forward – it feels as though we’re on the cusp of building something truly revolutionary, something that could render corporate social networks completely redundant for virtually everybody. But, despite all of our advancements, it remains just out of reach.
Over the years, I’ve been studying a handful of different fediverse platforms that bring a lot of interesting concepts to the table. As someone that has studied and reported on the developments of these various systems, I’ve decided to put together a summary of things I’d like to one day put into my own federated platform, should I ever develop enough brainpower to actually develop one.
Disclaimer: It’s entirely possible that I’m a complete moron, fail to grasp the domain areas these problems stem from, and that the solutions I’m talking about aren’t solutions at all. Feel free to ridicule me.
It’s also worth mentioning that this topic is largely about features, not the bigger and more complicated topic of how a bunch of independent platforms extend an existing standard and build for interoperability.
1. Unified User Account
One of the major boons that the fediverse advertises is that, hypothetically speaking, you can follow any platform from any platform. An end user can follow a PeerTube channel and watch videos from Mastodon, and can also comment on Plume blogs from the same account.
This is generally a great thing! However, the current implementation has two downsides:
- Type Asymmetry – Some fediverse platforms don’t support the same activity types as others. A PeerTube channel can’t get status updates from Mastodon, because it’s not really designed for that use-case. Plume users can’t upload videos, PeerTube accounts can’t listen to Funkwhale tracks, and PixelFed can’t play PeerTube videos.
- Account Proliferation – Because of the way things currently are, especially in context with the last point, it’s totally possible to have a bunch of accounts for different platforms. I personally have at least 6 accounts: I post status updates on Pleroma, photos on PixelFed, videos on PeerTube, music on Funkwhale, community group posting on Lemmy, and book reviews on BookWyrm. There’s probably a handful of other accounts I can’t even think of right now! Regardless, this leads to a user having their content and interactions broken up into 5 or 6 distinct streams across several different apps, rather than unified in one place.
Type Asymmetry
The solution to the first problem seems fairly obvious: for a generic social server, it makes sense to support the maximum amount of Activity Object types, which could probably be summed up as: “Note, Article, Image, Audio, Video, Place, and Event”, with support for Actor types of at least “Person and Group”.
Granted, not every piece of software in the ecosystem necessarily has to support this – Mobilizon, a federated events system, probably has no reason to care about PeerTube video activities or Funkwhale music activities. But, Mastodon or Pleroma might be interested in activities from all three.
Account Proliferation
The second problem is a little bit trickier, but I think the answer can be traced back to one of the core concepts that the Tent protocol was trying to achieve: link everything back to a user’s server.
In Tent’s world, a user has a core server that holds all of their data, and then basically does an OAuth dance with several applications that are all capable of rendering different activity types. The data stays on the user’s Tent server – apps are just different frontends for that data. Contrast this against the current fediverse, where each instance in the network is a fully-realized stack with built-in federation.
What I’m really envisioning is as follows: everything a user wants to do can be represented on the backend of their own instance, but broken out into different contexts on the client side through different frontends and applications.
In fact, the same data can be re-used through different apps: maybe my mobile Twitter-Clone app only supports status updates, pictures, music, and videos, but maybe my mobile Instagram-Clone app only supports photos and videos. Both apps would still point to my server, and my profile would be a linear stream of objects relating to every service context that I’m using.
To be clear: I don’t think the right direction is to solely move towards an “everything is an app, and the server itself is headless” model. Instead, I think a good path forward is more along the lines of: the core server supports a bunch of types, provides a bundled interface that can be swapped out (Pleroma is doing this now), and is supplemented by various desktop, mobile, or web clients that are built around a particular set of experiences.
2. Every User is a Moderator
Well, maybe that sounds a bit hyperbolic. I don’t mean that every user has mod powers across instances (eg, someone on Mastodon.social moderating someone on shitposter.club), or that users on every instance has moderator capabilities of their entire home server (imagine Mastodon.social with 621,000 moderators). That might be chaotic.
One of the things I’ve been thinking about is that federated social platforms should instead give users maximum moderation powers over two things:
- Who gets to see what?
- What do I want to see?
Who gets to see What?
User moderation tools have come a really long way since the early days of diaspora*, where all a person could do to manage a harasser was hit the “Ignore” button and reach out to the people running their instance about the problem. It’s still not a perfect situation, but modern platforms like Mastodon and Pleroma at the very least have capabilities for blocking bad actors and silencing them.
The question is, how can this be expanded upon in a useful way?
I think the central goal should be to bring more capabilities down to the user level, rather than uphold a system that relies solely on moderator teams and admins. What might this look like?
Avoiding Context Collapse
When it comes to traditional social networks, it’s not uncommon for different groups of people to fall into different buckets, based on what platforms they’re on. From there, different conventions and expectations arise from those respective pockets of the Internet. In a federated system, the lines between sites becomes increasingly blurred.
What I’m trying to describe here is Context Collapse – where different social groups with different norms and expectations become folded into one. What’s appropriate for one context (FetLife) might be inappropriate for another (LinkedIn).
Some fediverse users handle this by creating alt accounts dedicated to a particular context – but this has always felt more like a hack than anything. Aside from registering an “After Dark” account far, far away from the original account, what improvements could we make for people who want to do everything, all in one place?
There are two concepts here worth talking about that actually have a bit of history: Aspects, and Facets. Both of these things might be accomplished today using ActivityPub’s concept of Collections.
Aspects
Aspects were the premiere feature of Diaspora* when it launched back in 2011. In short, an Aspect is basically a set list of contacts: Friends, Family, Work, Whatever. A user can create as many Aspects as they’d like, and easily manage who got to be in which Aspect.
When posting, this created a dropdown menu to define visibility scope: which groups of contacts get to see this thing you’ve posted? From there, some magic key-signing happened in the backend, and private statuses would only get sent to those groups of people. In addition, you could also use Aspects to filter your timeline, to see statuses coming directly from that bespoke collection of contacts.
If you’re not in the group and somehow stumble onto the exact URL where the post lives, you just see a generic 404 message saying nothing is there, and you won’t see the responses your mutuals might be making to it, either.
Aside from Diaspora and platforms derived from Friendica, no other fediverse platform really seems to leverage this kind of message scoping. Platforms aligned with Mastodon pretty much only use Public, Unlisted, Followers-Only, and Direct as privacy scopes.
Facets
This is an inverse concept to Aspects, and to date, I’ve really only seen platforms based on Friendica do this. These platforms don’t even have a word for it beyond “multiple profiles for the same user”, but that doesn’t even begin to describe what it is. So, I’m calling these things Facets.
What is a Facet? To put it simply, it’s an additional profile tied to a singular user account, where certain fields are only seen by certain groups. This creates a comprehensive alternate profile where data fields and posts align to form a comprehensive persona.
So, I can throw a bunch of professional contacts into a Work aspect, and then associate them with a special profile that only shows up for them.
Everyone that’s not a work contact gets sorted into an alternate collection, and gets to see me as Wild Party Man.
All joking aside, it’s 100% possible to create a kind of social software that gives a user the ability to totally control how they present themselves to different groups of people simultaneously. This might be worth exploring, allowing one account to self-filter based on what’s important to it.
Permission Scopes for Activities
From a user perspective, it might make sense for users to dictate who can see their statuses, and who can interact with them. I would make the case that this is fundamentally important
Within the last few years, Twitter has been following a model where users can stipulate which people are capable of replying to their tweets. As stated above, Diaspora had Aspects, which dictated who could even see a private status in the first place.
Maybe some combination of those two things are necessary to reduce the amount of shitty interactions one can have when dealing with campaigns of harassment from trolls.
The trick is getting it to work reliably – what if one server doesn’t conform to another’s implementation for blocking, or private statuses, and simply evades those restrictions? The old attitude that GNU Social developers used to have was basically along the lines of “We can’t actually implement privacy in a meaningful way, so don’t bother implementing it.”, but I think that’s kind of a defeatist attitude.
Object Capabilities
The biggest advancement on this front might be from what Christine Webber is doing with CapTP and Spritely. It’s a little bit over my head, but the core ideas can basically be explained as: “Nodes in a network don’t have to fully trust each other; instead they should operate with mutual suspicion and act accordingly. They can use a standard set of instructions.” This can be further described using The Object Capability Model.
In a nutshell, the Object Capabilities can be thought of as “an unforgeable reference that can be sent in a message”, where a message “specifies the operation to be performed.” The Spritely Goblins docs helpfully offer this explanation:
“Furthermore, “object” in “object capability security” refers to security based on holding onto references to an external entity. What you hold onto is what you can do.”
— Spritely Goblins documentation
In other words, it’s supposed to be a secure way for a server to specify what operations are allowed to be performed on a resource – kind of like a contract mechanism that only gives up the goods if very specific requirements are met. Christine is doing some amazing research into the subject, and the fruits of her work might ultimately be the mechanism that people use to stipulate a set of conditions for mutual interaction.
Maybe this work will provide a foundation, where user rules locally stipulate what happens to their posts – if a user blocks or silences a troll, perhaps the troll’s responses will fail to append to a conversation tree. Or, perhaps the user’s server will refuse to show the post to the troll at all.
What does The User see?
Okay, so we’ve talked a little bit about having better control over who can see and interact with your own stuff, but what about having better control over what you can see? This is still something of a budding area: historically, people have relied on RegEx and word-lists to filer out statuses containing terms they don’t want to see, but this is actually pretty limited.
One of the most brilliant tools I’ve seen come into the space is Pleroma’s own MessageRewriteFacility, henceforth known as MRF. Basically, there’s a component at the server level that can interpret rules. Let’s look at the example SimplePolicy config that the docs use:
config :pleroma, :mrf,
policies: [Pleroma.Web.ActivityPub.MRF.SimplePolicy]
config :pleroma, :mrf_simple,
media_removal: [{"illegalporn.biz", "Media can contain illegal contant"}],
media_nsfw: [{"porn.biz", "unmarked nsfw media"}, {"porn.business", "A lot of unmarked nsfw media"}],
reject: [{"spam.com", "They keep spamming our users"}],
federated_timeline_removal: [{"spam.university", "Annoying low-quality posts who otherwise fill up TWKN"}],
report_removal: [{"whiny.whiner", "Keep spamming us with irrelevant reports"}]There’s a couple of things going on here:
media_removal: strips out all media attachments coming fromillegalporn.biz.media_nsfw: applies anwfwtag that puts media attachments coming fromporn.bizbehind a Content Warning.reject: straight up drops all messages coming from the domain ofspam.com.federated_timeline_removal: accept messages fromspam.university, but prevent those statuses from ever showing up inThe Whole Known Networktimeline.report_removal: ignores falsified reports coming fromwhiny.whinerthat have been excessively queued up for spamming purposes.
MRF is incredibly powerful…but the downside is that this all sits at the admin level, and requires admins to manually edit configurations themselves. Bringing these capabilities down to the user level, and putting it into a GUI that’s simple and straightforward, would go a long way towards filtering out unwanted crap without wholly relying on admins to do everything for you.
3. Migrating Between Servers
One of the age-old problems fediverse applications struggle with: “If I decide to move over to another server, how do I take all of my stuff with me?”
Whereas the term “stuff” can refer to:
- Statuses / likes / messages
- Media
- A list of who that account is following
- A list of accounts that are following that account
- Profile Data (avatar, header image, bio)
This ends up actually being pretty messy. Historically, most fediverse platforms only let users export a little bit of their profile data and list of people they follow with them. It’s possible to update your old profile to a Tombstone that points to your new profile, but that doesn’t really help you if your old server has been completely destroyed beyond repair. It doesn’t even bring your followers from your old profile to your new one.
Nomadic Identity
Some years ago, Hubzilla came up with a concept called Nomadic Identity, and it’s pretty fucking wild. Essentially, a user takes their existing account, clones it to another server through a profile import system, and then does an authorization handshake to say “Yes, I created that clone, it belongs to me!”
That clone and its parent can then act as relays for one another. If you post in one place, it gets mirrored to the other place. Interactions and notifications show up in each place. And the best part: your followers barely notice a difference. In fact, your stream on both ends can look virtually the same, since the data is synced between both channels.
Nomadic Identity seems like it might be the solution the fediverse needs for easily migrating around from one instance space to the next. Generally, the relay system it provides helps to bring censorship resistance to the network, and can help users move away from instances that might not be around for much longer. However, a few outstanding questions come to mind:
- How could a rogue admin mess this up for users? Is it possible to absolutely mangle the data that gets exported so that migration isn’t possible? Can an admin abuse secure access between two relays, and log into another instance through someone else’s relay on the admin’s instance?
- How might this look for migrating from one platform to another? Is there a future where it might be possible to easily migrate everything from Friendica into a Pleroma instance, for example?
- Generally speaking, the ability for users to resist censorship can be considered a positive thing. But, a larger question opens up: how might a user avoid being dogpiled by a troll using a bunch of different clone relays? It’s one thing to be able to block incoming content from a bad domain, but the problem becomes stickier when the attacker has clone relays scattered across friendly instances.
4. The Discovery Problem
I’ve written about The Discovery Problem in federated systems before, but here it is again in a nutshell: for a new user to stick around and continue to use a federated social network, there needs to be content that the person is actually interested in…but, sorting through the junk to find the good stuff is actually super hard. The situation can be so frustrating that people just give up on it.
Tag Following
Aside from Aspects, one of the other early innovations Diaspora* gave to us is the ability to follow tags, in addition to other people.
The mechanism itself was pretty neat: for any hashtag that you can think of, you can follow it, and tagged content will automatically insert itself into your stream. It took very little effort on the part of the user, and often brought a lot of interesting posts from the network directly to them.
Full-Text Querying
A newer development on platforms such as Mastodon and Pleroma includes the ability to conduct searches by keyword, instead of just relying on the tagging system. For discovery purposes, it’s great: you can see who’s talking about a given subject regardless of whether they bothered to use the tag index at all.
The feature remains a little bit controversial, and some instances actually disable it. The argument goes a little something like this: this method of querying opens up a can of worms for harassment, because a troll can simply look up a person’s name or some aspect of their identity and use that discovery mechanism to embark on a campaign of misery-making.
While that’s certainly a compelling argument, I think it actually makes a stronger case for Object Capabilities and more robust Privacy Scopes. The common factor that I find myself coming back to is that some user-level moderation tools are still kind of feeble, and some mechanisms purporting to deal with the problems once and for all end up getting subverted, because the core problem is deeper.
I’d like to believe that there’s a world where both ease of discovery and mechanisms to protect against harassment can in fact exist in tandem, and that this doesn’t have to be an either-or situation.
Topics, instead of just tags
Hashtags have long been a venerated way of appending content containing a tag to an index for discovery purposes, but unfortunately, it’s very limited. For example: let’s say that you were using the tag following mechanism that I just described, and you decided to follow #FreeSoftware, because you’re super interested in that.
But, suppose that not everybody used that particular tag? Maybe some people use #KDE to talk about the K Desktop Environment, and other people use tags for specific apps to talk about those? You potentially end up missing out on all kinds of stuff, simply because people use other tags in their posts.
The idea of a Topic object is simple: it’s similar to a hashtag in that it’s a content index, but…instead of relating to one specific hashtag, instead it relates to an array of different hashtags. Heck, maybe it even contains query terms, to check for posts that mention it, but don’t explicitly tag it.
Unfortunately, this concept doesn’t yet exist in any fediverse app, but the idea of joining indexes together in this way, and using it as a mechanism to bring interesting content to the user, might be a good way to cut through all the noise and show stuff they’re actually interested in.
Maybe this kind of thing could even serve as a type of Query Builder, where people can also stipulate what kind of topics they’d like to straight-up avoid seeing.
A Directory System
The Friendica family tree of platforms incorporate some kind of directory structure to make search and discovery easier for end users. Directories kind of work like a rudimentary search engine crossed together with a phone book.
Generally, the directory system offers two major scopes:
- A local directory of people on the site
- A global directory, shared between instances, of everybody.
In the example above, it’s also handy for discovering other types of actors, not just regular old user accounts: People, Organizations, Forums, and News appear as potential filters. As long as you opt-in to being indexed, your profile shows up in directory results.
What’s interesting is that, aside from platforms originally developed by Mike Macgirivn, the only other fediverse platform that seems to offer some kind of user directory is Mastodon, and the listings are incredibly sparse – although I suppose it looks a lot more slick, there’s virtually no way to sort or filter the list, and very little information of any kind.
In short, I think that having a robust directory tool would significantly help more people connect with one another. Obviously, even a feature like directories need to account for user privacy – for example, if somebody blocks you (or you block them), that person shouldn’t appear in the results.
If you’ve been with me this far, and have a good grasp on where I’m coming from, you might say “Ah! These things already exist in a platform! You’re clearly talking about Hubzilla and the projects that descended from it!”, and to some degree, you’re right.
Unfortunately, I strongly disagree with Hubzilla’s approach: it tries to do everything in a singular context, and its interface suffers from the density of a black hole. I have much admiration for the project, and many of my thoughts are inspired by it, but I think the UX requires special treatment to get right.
The core problem of Hubzilla’s design is not necessarily that it tries to do so much, but that its individual parts sometimes don’t follow the design conventions of the larger system, and users end up having to wade through an ocean littered with disconnected configuration menus to get the behavior they really want. You can configure the heck out of it and eventually get to a pretty comfortable setup, but at times it feels more like a kit for assembling a platform than anything else.
What I’m interested in is a system that allows for consistency and simplicity as the default, where the actual magic trick is that the default is in fact just a preset of configurations sitting on top of an infinitely configurable system. Unfortunately, that means that said system has to be built from the ground up.
In Conclusion
This is merely a summary of some of the biggest “top of the head” musings that I could come up with at this time. There are a lot of other big moving parts to consider, too:
- How can we make frontends more customizable, to the point that users can easily build their own and have stuff “Just Work” with an underlying platform? (This was originally Point #5, but the concept is so big that it warrants an entire write-up).
- How does a loose collective of independent projects move forward on new features while maintaining compatibility?
- How do we deprecate older ways of doing things for better methods if the biggest players don’t care about them?
- How on earth can these projects and the people running the infrastructure make enough money to stay afloat for years?
- How do we prepare a system to migrate everybody off of corporate social silos en masse, so that we may effectively kill those services forever?
- Will the fediverse ever be private enough / robust enough/ secure enough / decentralized enough?
I don’t have answers to these questions yet, and only the loosest of stray thoughts. A lot of the bigger answers here go beyond what software is capable of providing, and rely more on mutual aid and collaboration between a countless amount of people.