Anti-Fuckbook campaign!

Ever is a long time. But in the near term, he's almost certainly right. Putting together such a massive project will need a lot of money, and the people who will want to invest that kind of money are the ones who will want to turn users' private data into an asset for sale.

Here's what I think would be required to create a libre replacement for FarceBook.

First, we'd need a large-scale, crowdsourced UX design project. This would involve current FB users explaining exactly what features they use and how they use them, and a group of designers gradually building up mockups of a replacement UX. The designers would go through a number of iterations of presenting their mockups to the users for feedback and tweaking their designs in response. The outcome 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, which ones would need new code, and how the whole service could fit together efficiently. This would be a complicated set of decisions, because although building completely from scratch would be reinventing the wheel, the alternative requires evaluating hundreds or thousands of potential dependencies for code quality, and how likely it is to be maintained effectively in the long term.

The third part of the project, once the choices about initial design and back-end component re-use/ development had been made, would be to put the whole thing together as a proof-of-concept service. At this point, people who participated in the original crowdsourced UX design project could be contacted to see if they would like to be beta testers. Again, there would need to be a number of iterations where the service and UI was tweaked in response to tester feedback.

Unless there was some way to create an entirely serverless system, during the prototyping phase some serious thought would need to be given to how to provision servers the production services will rely on. Our experiences with the fediverse so far have shown that we can't just rely on random people setting up instances, which may vanish without a trace at any time. If the FB-replacement ties users to a domain name, as the ActivityPub fediverse does, there will need to reliable organizations running instances (like cooperative businesses, associations with paid membership, or well-funded charities). It would be better if it used Zot (like Hubzilla and Zap), 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. But in the absence of a serverless system like Jami, the long-term organizational and financial durability of instances is a problem that needs to be solved before federated social networks are ready for mainstream use.

Once the alpha and beta phase of prototyping was finished, and a stable 1.0 release of both the client-side apps and server-side software was available that included tools for importing users' data from their FB account, there would need to be a massive organizational and promotional effort to get reliable instances set up, and convince groups of users to set up accounts and start using them.

Some might say I'm making this seem way more complicated than it needs to be. After all, we've already created a federated replacement for the birdsite. But my whole point is that FB is a much more complicated system to replace and people are much more dependent on it.

The birdsite has only two features, a public micro-blog (short text messages published on the web), and private text messages, and the fediverse as a whole has only implemented the first one. Some fediverse apps have "private" messages, but they don't yet federate reliably across all apps and most (eg the Mastodon/ Pleroma DMs or "direct messages") are private only in the sense they are not displayed publicly on those platforms. DMs sent to servers running other fediverse apps are liable to just treat them like any other public post. Only servers running Zot apps have any kind of encryption or proper controls over private messages and media.

FB consists of a wide range of features; not just posts, but an event 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. 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, and the problem of hosting remains unsolved.

In summary, I'm sceptical because I think that rather than replacing FB with a single service, I think we're more likely to succeed by disaggregating its features, replacing them with apps that do one thing well; chat clients, media-hosting services, events systems etc, and finding ways to bundle them together into hosted services, and make them inter-operate widely.