#meta and the messy path we are going down, Libertarian cats are completely pointless at this stage of mess, anyone got ideas for a plan?
What is a good path on this?
My thinking is that #FOSS governance is based on #feudalism and that the thing you learn from history is to never trust a king.
Avoid federating as much as possible. I know that some people are counseling against this, both on grounds that it doesn’t achieve much, and that it cuts P92 users off from an exit route off of Meta products, but limiting their embrace is a necessary prerequisite for keeping our interests separate from Meta’s as a company. The more we integrate with their built-in community, the more difficult it will become to argue against extensions and protocol changes that serve their interests more than those of the communities built on FOSS services. Social integration with Meta’s userbase allows them to argue against features and changes that don’t serve their bottom line, as though their position ultimately served the good of the network. Their strategy will almost certainly be to make their implementation the small end of the lever, so that changes they make to their app practically require changes in AP-native services in order to prevent significant friction in people’s experience of the fediverse. At a certain degree of integration, it will become nearly impossible to distinguish between what is best for the network and what is best for Meta, at which point, they will have effectively won control of the protocol.
Focus on building functionality for independence. Much of the development thinking and work that I’m aware of at the moment is focused on replicating the functionality of commercial social media services. It should be fairly obvious that the more like those services we make the fediverse, the easier it will be for them to assimilate us. For example: I’ve written before about two conceptual approaches to fediverse instances. The view that instances are Just Nodes for connecting to the network at large ultimately lends itself to commercial ends. The more tools that we provide for instances to build relatively self-sufficient communities, the better insulated the whole network will be against EEE tactics. As a corellary, we should be in a constant process of reassessing the tools and projects we have in progress, with an eye toward who they benefit more: independent communities on a FOSS network, or companies looking for ways to centralize social activity around their own profits.
Grow hawkish on protocol governance. Ultimately, the success of an EEE attack depends on the ability of the commercial entity to co-opt the governance over the tools that sustain a FOSS community. A successful Embrace phase makes that easier by aligning the perceived needs of the community with the imperatives of the corporation, so that they can argue, for example, that making monetizable user data easier to track serves the community because it also happens to make it easier to migrate a user’s post archive when they change servers. But even if we undercut Meta’s Embrace strategy, we should expect them to push toward an Extend phase in which they effectively shape development by making the costs of breaking compatibility increasingly steep. Focusing on maintaining the independence of the protocol and its utility for independent communities is key to resisting assimilation on that front.
lets see if this ages well; given everyone that I have worked for/with in the last 40 years has nicked named me “Cassandra”, my hunch is it will survive.
Fediverse as it is now is never going to take root as the ubiquitous predominate standard like say TCP/HTTP/FTP/CGi or even NNTP did with Usenet or even Tomcat did with Servlet containers in the Java world.
I even wrote proof of concept of my app using RFC1036 just to prove it was quicker to build it that way; took two days; than the three months I spent jerking around with ActivityPub/Streams specs.
Most of the AP/Streams concepts are there in the latest specs RFC5537 and implemented for a decade now.
I have posted why before; the TL;DR is it is way too complicated, way too many edge cases; because it is way too inheritance based OOPy and kitchen sink in design.
The best you are going to expect to get adoption wise is where you are at now for these reasons. There is no basic implementation that people can build upon, they have to recreate support for the entire spec from scratch.
I am working on a startup that 100% fits into the “Fediverse” idea; but it is 1000% too expensive time and space wise to implement support for it, I went down the road and scrapped all that code, I was not actually working my startup but supporting a spec I realized after a bit too much time, I did not need.
At best, my support for ActivityPub/Streams and Fediverse in general will be to write a proxy/facade implementation that does some basic translation to MAYBE send message, but not consume anything.
I will have my own proprietary api and if there is demand AND time AND money, I MIGHT implement this sliver of support.
Look at kitchen sink heavy APIs that are DOMINATE, and none of them are defacto standards; WordPress is the dominate CMS by a long shot; very few non-WordPress products support their API completely. And when they do it is for supporting TOOLING apps to manage their server, not to actually support WordPress ecosystem stuff. Mainly to support ingesting and exported WordPress sites data, just for conversion to their system. Same for Facebook.
Twitter and Reddit are making the case to not base your business model on any companies APIs, which could be played in favor of the Fediverse, but when you look at implementing what Twitter and Reddit API’s do, in Fediverse SPECS your eyes glaze over; say screw this complexity and just do what Twitter or Reddit or whomever did and try and fix what you feel are mistakes/missteps they made.
The specs need to be broken up into small implementable very specific pieces as reference implementations. Ideally as plugins or extensions to already established OSS code bases.
Then the “kitchen sink” features that 99% of the potential developer base does not need to use can be defined as optional extensions of the mandatory minimal interface. Kind of like WebDAV over HTTP does. I implemented WebDAV in Java and Python clients AND servers in three days by myself back in the mid-2000’s. WebDAV as a standard is not really used in practice but the concepts it introduced still are.
You want adoption without pollution; give developers code that “just works” and they do not have to write, with simple examples for the most common uses cases.
Embracing the IETF motto – “We reject kings, presidents and voting. We believe in rough consensus and running code” – along with the ethos of permissionless development, we need to address the limitations of our current systems.
ActivityPub, though effective, carries a significant amount of technical debt, and its federated model can be considered a weak point. We should strive to continuously expand the ‘verse’ and construct bridges to other systems. Examples of such successful bridges include those to indieweb and nostr, via mostr and hopefully soon brid.gy.
In my view, we have always required open alternatives to meta products such as Facebook and Instagram. The emphasis on blogging and microblogging through platforms like Ostatus and openmicroblogging, coupled with the current form of ActivityPub, has inadvertently offered Meta a competitive advantage.
It’s time we developed a comprehensive open social web. While ActivityPub plays a role, it represents only a fraction of the entire social web - analogous to the notification popup on Facebook. There’s still a pressing need for a robust Facebook clone. Despite being late, it’s a necessity for a more open and balanced digital social space.