Farcebook: One Thing To Rule Them All
The challenges of developing a privacy-enhancing everything app.
Here’s another one I prepared earlier. Originally posted under the same title on CoActivate1, in the innocent halcyon days of early 2019, it’s been heavily rewritten to bring it up-to-date2. I offer it as a follow up to the Get a Room piece I posted a couple of weeks ago, on the challenges of creating reliably private social spaces within decentralised networks.
FarceBook have been getting a lot of heat since the Rohinga genocide, and for good reason. The mass grumbling that began with scandals like Cambridge Analytica has escalated significantly. To the point that digital serfs are reaching for their pitchforks, and opportunistic politicians are proposing “reforms” that suits their own agendas3.
What’s really required to fix FB is to replace it, with ethical services controlled by the people who use them rather than tech corporations, or their data buyers and advertisers. But so far it seems the only people talking about solutions this ambitious are the software freedom movement, and the people building the fediverse and other decentralised networks.
Many project teams set out to create a full FB replacement over the last decade. But rebuilding such a swiss army knife of a platform - especially as a single app - is a road littered with the corpses of lost pilgrims (and their horses). For example, three attempts I’m familiar with are Diaspora, Friendica and OpenBook (later Okuna).
Diaspora ended up as more of a federated LiveJournal or Tumblr. A couple of dozen Diaspora services (or “pods”) are still around, federating with each other and a handful of fediverse apps that implemeted their protocol. But the flagship pod at joindiaspora.org shut down a few years ago, and at this point I think it’s fair to say that like GNU social4, Diaspora is a spent force.
Friendica remains more viable, with a few hundred services running the software. Federating with other software over both Diaspora’s protocol and the more commonly used ActivityPub. But although it got a few steps closer than Diaspora, it’s still a long way from covering the ever growing list of features people go to FB for.
OpenBook is the saddest case I’ve seen, a classic example of NIH syndrome5 . In 2018, 22 year old founder Joel Levi Hernández Fernández raised NZ$110,584 on KickStarter to build a new everything platform. Just like FB except “open source”, publishing the code for their software under a free license.
This plan wilfully ignored the plethora of centralised social platforms that had already tried and failed to make a dent in FB’s growth (eg Ello, launched two years earlier). It also ignored the slow but steady growth of existing Free Code social media networks. Which by 2018 had been using open protocols to exchange hot takes, memes and cat photos with each other for years.
Fernández praised the network of services running software like Diaspora, Friendica, GNU social and Mastodon (a relative newcomer at the time). But specifically ruled out trying to federate, even with other services that used the OpenBook software (“instances”).
“We want to give our users absolute control of their data. We want them to be able to see the exact physical location of their data and to be able to ensure its deletion, even when shared with third party applications.
Protocols for interconnection between social networks such as ActivityPub rely on independently distributed networks to accomplish this.
These networks, being independently distributed, make these items impossible to guarantee.”
So the plan was for a single service run by a crowdfunded startup to relace the largest social platform in the world. All by itself. Riiiiiggght.
After cease-and-desist letters from FB over the name, the project was rebranded as Okuna, and Fernández raised another round of crowdfunding on IndieGoGo. This time raising NZ$200,323. In 2021 he was at it again, making essentially the same promises, this time back on KickStarter under the name Somus.app.
Fernández did at least publish some source code for Okuna. Which is still available on GritHub if anyone wants to fork it, although I don’t know how useful that would be. But a couple of years after the Somus crowdfunder, this one too seemed to sink without a trace. This time with no source code available. A cynic would accuse him of running a scam, and people have6.
So, considering all these partially successful and totally failed attempts to replace FB, is it really viable? Here’s what I think would be required to create FB-killer.
First, we’d need a large-scale, crowdsourced UX (Use eXperience) design project. This would involve people explaining exactly what FB features they use and how they use them. Then a group of designers gradually building up mockups of a replacement UX, using something like PenPot.
The designers would go through a number of iterations of presenting their mockups to some of those people for feedback. Tweaking their designs in response. The goal of this project would be a coherent UX design, for both a website and native apps, for desktop and mobile platforms.
During the course of the UX design project, a list of required features/ functions would need to be compiled. Decisions would need to be made about which of these could be implemented on the client-side (as many as possible, particularly data storage) and which would need remote servers.
The second part of the project would involve identifying which of the features required by the UX could be implemented using existing Free Code components, and which ones would need new code. As well as how the whole service could fit together efficiently. This would be a complicated set of decisions.
Building completely from scratch would inevitably result in reinventing the wheel. Missing many opportunities to leverage the work already going into like-minded Free Code projects. But to take privacy seriously, the alternative would require evaluating hundreds or thousands of potential dependencies. Both for code quality, and for how likely they are to be effectively maintained in the long term.
The third part of the project, once choices about initial design and back-end component re-use/ development are made, would be to put the whole thing together as a proof-of-concept service. At this point people who participated in the original design project could be contacted again to see who would like to beta test. Again, there would need to be a number of iterations, tweaking the service and controls in response to tester feedback.
Unless there is some way to make a platform replacement an entirely serverless system, like Jami or Briar, questions inevitably come up about who provides the servers to run copies of the server software (“instances”). As our experiences with the fediverse so far have shown, we can’t just rely on random internet strangers setting up services, which can vanish without warning at any time.
The long-term organisational and financial durability of these services is a problem that needs to be solved before federated social networks are ready for mainstream use. So during the prototyping phase, some serious thought would need to be given to how to provision them.
If our FB replacement ties accounts to a domain name, as the ActivityPub fediverse and the Matrix network do (unlike Nostr and in theory BlueSky’s ATProto), there will need to reliable organisations running the services. Cooperative businesses, associations with paid membership, or well-funded charities, for example. It would be better if it used Nomadic Identity (like Hubzilla and Forte), configured in such a way that every user’s account exists on at least two instances at any given time. So if one goes down, the account is automatically copied from the surviving one to another one.
Once the prototyping efforts produced a stable 1.0 release, for both the client-side apps and server-side software, there would need to be a massive organisational and promotional effort to get reliable instances set up. As well as convincing groups of people to set up accounts and start using them together. Ideally the 1.0 release would include tools for importing peoples’ data from their FB account. A task that FB do everything in their power to make as difficult as possible, despite various attempts to legally madate it.
Some might say I’m making this seem way more complicated than it needs to be. After all, we already created a federated replacement for Titter (now Xitter). But my whole point is that FB is a much more complicated system to replace, and people are much more dependent on it working reliably.
FB consists of a huge range of features. Not just posts, but a calendar and event invite system, encrypted realtime chat (including voice/ video), photo-sharing and galleries, web video and video livestreaming, pages, groups, and more. Many of these features have both public and private versions. While FB’s privacy protection is far from exemplary, a system being promoted as an ethical replacement would need to take this seriously.
When the first fediverse developers set out to replace Titter, it had only two features to copy; a public micro-blog (short text messages published on the web), and non-public text messages. As I pointed out in the aforementioned Get a Room post, the fediverse as a whole has only implemented the first one. Some fediverse apps have non-public messages, but most are not encrypted, so they’re private only in the limited sense that they’re not displayed publicly (eg “Private Mentions” on Mastodon posts).
Servers running Nomad apps do have encryption and access controls for private messages and media, and work is tentatively underway to fold these features into ActivityPub7, so they can be used by other fediverse apps. But for now, they only work when messaging from one Nomad service to another, and it’s far from clear how backwards-compatible Nomad is with older versions of the protocol8.
In summary, many existing Free Code projects offer some of the elements needed to create a FB replacement. But none of them are anywhere near incorporating them all. Even if one achieved this, the ongoing maintenance burden would be huge. The problem of sustainable hosting for them remains unsolved.
So I’m sceptical about trying to replace FB with a single service, even a federated one. I think we’re more likely to succeed by dis-aggregating the everything app’s many features. Replace it with many apps that each do one thing well; chat clients, media-hosting services, events systems, and so on, and find ways to bundle them together into community-hosted services that can interoperate with each other.
Image:
"Jack the Giant-Killer, 1864" by Toronto Public Library Special Collections, licensed under CC BY-SA 2.0.
"Dr. Evil at CES" by krynsky, licensed under CC BY 2.0.
For some reason the WayBack Machine doesn’t have a single capture of the page for the piece itself, but it’s in this list of posts marked ‘open social networks’ if you scroll down to the fourth piece there.
I always notice when reposting these pieces that the more things change, the more they stay the same.
While people who have been arguing for decades that digital rights are humans are being smeared as stooges of the DataFarms.
Originally StatusNet, as used on identi.ca before it was migrated to pump.io software.
By writing specs for them as FEPs (Fediverse Enhancement Proposals).
Nomad is the final iteration of the Zot protocol, as used in Hubzilla and Zap, of which there were a number of versions, and before that the DFRN protocol used in Friendica.