Introduction
A year and a half ago, I wrote about what a federated replacement for Facebook would look like. Part of that was differences from Facebook, and another part was differences from Mastodon, the leading federated social network software. Since then, I’ve used Mastodon a lot more, Mastodon has added and changed features, and my thinking has evolved, so I feel like it’s time to write an update to that article.
On the other hand, I haven’t used Facebook at all in that time, so my perspective on Facebook hasn’t updated, and this update is going to focus more on differences from existing Fediverse software.
How a federated Facebook replacement would be different from Mastodon
More space for individual posts
One thing I emphasized heavily in my previous article was the presentation of posts:
IMO one of the main drawbacks of Mastodon is that posts are displayed in a very compact and uniform way, with links being presented only as literal link text.
Different post types should be presented differently, and in general, it should not really be up to the user to type in URLs or @references in the body of their posts in order to have links or to tag someone.
A client could parse OG tags on the target, but this really should be done on the server.
In the meantime, Mastodon implemented preview cards, and now displays previews inline in each toot. Links are still also displayed inline, and tags and @references are still inline, both consistent with its Twitter-like heritage. And toots are still displayed in a very compact and uniform way, even with previews added.
There have also been a couple of alternative Mastodon interfaces implemented in that time that give individual toots a lot more space, notably Pinafore and my own brutaldon. Both of these apps are heavily shaped by the Mastodon API, though, which brings me to my next point:
Comments and threading
The main standing difference between Mastodon and a Facebook replacement is the handling of comments and threading. In Mastodon, all posts are effectively top-level, and other than some options in the UI to filter out replies from timelines, replies and original posts are treated identically. Your home timeline may contain out-of-context replies, and, indeed, replies to posts you cannot see.
A more Facebook-like UX would treat replies fundamentally differently, as something that is only shown in the context of a post. Mastodon threads are always shown in relation to the “focused” toot: you see its lineal ancestors and the full tree of its descendants, but you never see the full tree of a thread unless the root post is focused. Threads are displayed flattened; there is no indicator, other than order, of what post is descended from what. In a Facebook-style UX, threading would be explicit; comments would be displayed differently from posts, marked by size and indentation, at least.
Comments would never appear out of context in your timeline. It’s an open question whether it would be a good idea for comments that would be visible to you (i.e., comments from people you follow) to boost their parent posts onto your timeline. If so, the parent post would appear in your timeline with a note: X (person you follow) commented on this post. The original post could be one that you would normally see (you follow the poster), or one that you wouldn’t normally, but could (a public post from someone you don’t follow). You would never have the Mastodon experience of seeing a reply in your timeline and being unable to read the post it’s replying to. Which brings me to:
Follower-only scope
Follower-only posts were a mistake. They work exactly opposite of how privacy settings in a social media app should work, and appear to be an accidental consequence of having Twitter-style locked/follower-only accounts, but also per-post privacy settings.
In a reasonable privacy setting, whether you follow someone and whether a post of theirs is visible to you are two independent variables. The first should be under your control (barring blocks), and the second should be under theirs.
Consider this scenario: Xenia likes to post political takes and comedy, but also nudes. On Mastodon, she locks her account (manually approves followers), so that she can post nudes with follower-only scope and be confident that only approved people will see them. Her SFW posts are posted publically. Ysidro likes to read Xenia’s political takes and comedy, and wants them to appear in his timeline. But he’s not interested in Xenia’s lewds, and doesn’t want to be creepy by sending her a follower request. With follower-only scope, there is no way for Ysidro to have Xenia’s public posts in his timeline; he must periodically read her profile page to catch up, or hope that someone he follows will boost her public posts.
In a more rational system, Ysidro should be able to follow Xenia and see her public posts, without her involvement (unless she blocks him). And Xenia should be able to post her lewds to a circle of approved users that she curates, that does not include Ysidro. And she should be able to post her sadposts or work gripes to other circles of approved users that may be completely different from her lewd circle. Ysidro does not need to know about the existence of these circles at all.
This situation is bad enough, but follower-only scope gets even worse when threading is involved. If you have 5 users in a thread, you also have 5 different sets of audiences (follower collections); normally a post inherits its parent post’s scope, but for follower-only posts, it uses it’s own poster’s follower collection, not its parent posters’s follower collection. So it’s possible and common to be able to read a thread and 1) not be able to see the top-level parent post, and 2) only be able to see posts in the thread from one or two of many people participating in it. This completely breaks any kind of threading context.
The audience to which a comment thread is visible should always be the audience of the original post (or, arguably, a strict subset of that audience — it can get narrower, but never broader and never just overlapping). If you can’t see a post, you shouldn’t be able to see replies to it. And if you can see a reply, you should be able to see all of its parents.
Can this be fixed on the front-end?
Some of it, yes. Others, no.
brutaldon is primarily a thin wrapper around the Mastodon API, and it doesn’t store anything about users other than their username, instance, and an access token. It fetches timelines or threads via the API, renders them, and forgets about them. Other than a check for notifications, it only makes one API call per page that it renders.
It would be completely possible for brutaldon to render posts and threads the way I talk about them above. Whenever it sees a post, it has to determine if it’s a reply and find the original post (one API call per page), then reconstruct the thread by fetching the thread as seen from the original post (one API call per top-level post), then convert the flat list of replies with reply-to ids to a tree structure (server-side processing), then render the tree. To minimize the number of API calls that it has to make, it would need to cache all of the posts that it knows about, preferably for a long time. This would be a huge change to brutaldon’s design, and it would be somewhat fighting against the Mastodon API, instead trying to act like a Usenet newsreader with the XOVER command.
I’m not going to implement this in brutaldon for user privacy and data retention reasons, though I could see doing it in another client; possibly desktop (GUI or TUI), so that I don’t have to worry about other people’s data.
Unfortunately, there’s no way to get around the problems with follower-only scope on the front-end.
What about Pleroma?
I haven’t used a Pleroma server yet, though I plan to. My understanding is that Pleroma has a more flexible back-end than Mastodon, but the client API is Mastodon-like, and the existing integrated front-ends are also Twitter-like in the ways that Mastodon is. Still, Pleroma could be one building block of a solution. Pleroma does support Markdown formatting in posts, which is one of many desiderata for a richer UX. There is also some talk of fixing the thread-breaking aspect of follower-only scope in future versions of Pleroma.
Other fediverse servers
There are a number of new servers since I wrote my previous article, but none of them fill this niche. There are several federated blogging platforms (Medium replacements), a federated video sharing platform (YouTube replacement), and a federated image sharing platform (Instagram replacement). There is a good list of them available, and I’m not going to review them here.
Groups and Events
No one implements these yet, though the building blocks for doing it are all there in the AP standard; it’s just something no one has wanted to take on, I guess. Calendars are hard, especially, because you have to deal with dates. Pleroma will probably get reasonable group support before Mastodon does, because they appear to take addressing more seriously. The really tricky bit is that, although it is reasonable to have separate accounts for video sharing and image sharing, groups and events are really things that you absolutely must have at least basic support for in your main account.
Why am I not talking about Diaspora, Friendica, Hubzilla, and Osada?
Diaspora implements essentially the correct privacy model. However, it doesn’t implement groups (only hashtag subscriptions, which are essentially public groups). It also has a highly toxic user community. It is also not interoperable with ActivityPub-based servers.
I don’t know enough about Friendica, Hubzilla, and Osada to comment. They seem to have fewer users or be harder to get started with, and have partial interoperability with ActivityPub-based servers. It is my understanding that Hubzilla does implement practically everything that I want here, if you’re willing to put in the time to assemble your instance out of the provided parts.
A halfhearted conclusion
In the last year and a half, the existing fediverse has become more of a solution for me than it was at the time, by adding features. The addition of card previews but especially the development of alternative front-ends, has improved the feeling I had that toots were too cramped, and too uniform. Pleroma and other servers are supporting longer posts and better text formatting. However, there’s still a way to go before it will be possible for me to read posts and threads the way I want to.
Postscript: If you are a Rust programmer, please take a look at Aardwolf. They are directly tackling this space, but are short on the developers they need to take on a project of this size.