You know I'm a committed user of the fediverse, perhaps this post will surprise
you. Still, at some point the truth has to be told, before lying leads to a
catastrophe.
I think I've been present in the fediverse (sometimes hosting a pod of some
software and sometimes not) since
Overall I get what you’re saying and sort of agree but…
I was in those socialcg meetings. What was agreed upon didn’t always make it into the protocol because mastodon devs had an outsized influence, and so even when the majority voted on certain things the chair went with what the Mastodon devs wanted.
And then to add insult to injury the Mastodon devs decided not follow the protocol anyway.
And then because MastoPub had the most users, many newbie devs thought that’s what they had to implement rather than AP.
And again, most of the things complained about by this person are due to that side of the story.
It’s a tragedy of history. And yeah, I guess you could call it a success story too but at what cost? What type of success story would we have had if it didn’t go down that way? I argue, much greater success, and much fewer people questioning whether fediverse is a good way forward.
Ah, thank you for that context. I was not on these meetings, but I did follow the e-mail conversations in the fedsocweb working group. And I vividly remember the protocol measuring contest that any suggestion of finding a common ground and choosing/designing a common protocol for the 50+ different, incompatible decentralized social media protocols devolved into very quickly.
At the same time, I was on Diaspora; and on StatusNet, which was all-but killed by Evan developing a yet another incompatible protocol PumpIO and just migrating the biggest StatusNet instance to it, thus tearing the heart out of broader StatusNet. The Network Effect worked against tiny, incompatible, decentralized social networks, and so we were all stuck in walled gardens.
Then comes ActivityPub and suddenly a dozen or so different decentralized social media projects talk the same language. The Network Effect starts working in our favour. That’s a big deal!
So that’s the lens I see ActivityPub through. Not saying AP is perfect. But it’s a large step in a good direction.
Done is better than perfect, I guess.
ActivityPub is the standardization of the ActivityPump (aka PumpIO) protocol, so all this came from that massive fuck you Even threw at the community. Set us back years, but we’re starting to see progress again these days I think, a little.
Well, progress is often not linear, or even monotonic.
But do they really talk to each other? They share Note objects at best. That’s to say nothing about how most still don’t really support urls as actors, and instead fall back on webfinger, which is deliberately not part of AP proper. And even then masto only supports alphanumeric names, so most new software copies that limitation to remain compatible, along with many other masto limitations. You are right about the lowest common denominator though.
Compared to, say, 9 years ago? When Diaspora would not federate with StatusNet, and Friendica would try to implement both of their protocols to try to create some form of interoperability between the two? With pump.io, tent.io, and Red doing things differently, and all this fragmenting the decentralized federated social media scene to a point of complete irrelevance?
When to the question I had asked on the
public-fedsocwebmailing list about how maybe, you know, there should be some effort to get different projects to speak the same protocol, the answers ranged from “not going to happen” through suggesting Bitcoin integration and claiming all these networks are too different to mentioning Usenet and NNTP.Today, thanks to ActivityPub (as imperfect as it is), from my Mastodon account I can follow PeerTube channels, WriteAs blogs, Mobilizon events, participate in threads like this one here on Lemmy, follow photostories on Pixelfed, and talk to people who have accounts on Friendica, Pleroma, MissKey, and who knows what other type of instances.
So yes, very clearly they do talk to each other, and very clearly this is already making a difference. Frankly I am flabberghasted this needs to be spelled out explicitly.
Of course, Diaspora still cannot federate with anyone else. But this is their choice. We now finally have a single huge network of different yet compatible (on a basic but important level) instances, so when a user asks “where should I move off of Twitter or Facebook”, different decentralized social networks need not fight among themselves to convince them to move to them specifically.
Instead of competing, a large number of federated social networking projects are cooperating, and surfing the Network effect together.
This is makes a lot of difference.
I haven’t yet followed your links but there are some things that came to mind from the comment text.
Mostly just that one of the reasons I liked both friendica and Red (who share a common author), was precisely the agnosticism toward protocol. The platforms do what they can within the confines of each protocol, and simultaneously support as many as they can.
There was a dearth of development resources on friendica when the founder left but it didn’t take long for the community to pitch in and catch up.
At least, that’s the way I remember things.
Oh, absolutely. I love the “yes, we will implement every single protocol we figure out how to, if we find the resources and time” approach. In fact, I advocated that very approach a lot some years ago.
But that only gets us so far — we end up with a network where a lot of federated social networks federate with Friendica/Red, but not with one another. That’s less than ideal.
So I much prefer a situation where we finally get a single protocol a lot of software implements, so that interoperability can be had in any direction. And that’s what ActivityPub brought to the table, finally.
note: I am new to the history of the ActivityPub standard.
Do you think that ActivityPub is capable of reform?
Do you think it would be possible to successfully propose to W3C that Mastodon doesn’t care to follow the protocol and those SocialCG decisions in their favor should be revised? What were some of those decisions?
Do you think Mastodon is increasingly in a position where it is ‘too big to lose’, and that if things escalated it would abandon federation with non-Mastodon platforms over following the majority-decided protocol? Will we see a situation where platforms are again using multiple federation protocols?
Hard to say. The data model has certain limitations that make it difficult to be used for more advanced things and it is structured in a way that seems to encourage nosql style document databases and has a sort of viral influence on the development of new apps.†
However, it can get the job done with enough brute force – though if you are doing anything other than microblogging MastoPub apps likely won’t work with it even if you are AP compliant.
No, the W3C process is such that the committee is closed and only addon specs can be ratified by the Community Group. I don’t remember any specific decisions but I remember at least a few occasions where everyone voted and there was a clear majority but the masto devs threw a tantrum and threatened to take their ball and go home. The results were mixed. Sometimes it simply went unspecified to “keep the peace” and others the majority was just flat out ignored and the opposite was put in spec. Excuses were always made and had me feeling like the whole voting process was a sham.
Not increasingly. It has always been that way. They don’t federate with non-mastopub platforms and the platforms that aren’t microblogs have had to limit their features to be MastoPub compatible.
The ones that have continue to do so and I still believe it’s the best (only) way.
@rysiek@szmer.info says that such a strategy results in apps that can talk with friendica or hubzilla but not each other, but I say that’s the situation we still have, where advanced apps can talk to each other but not Mastodon.
There will always be fragmentation. If that fragmentation falls on the majority (Mastodon) being inconvenienced I think that is a better result than the freedom fighters and innovators being sabotaged and having no options at all.
– ** –
† Here I am referring to the problem when developing a new app where if you plan to support AP first and foremost, it is easiest to structure your whole app and data model around AP, and then you are kind of stuck in that mindset permanently. Whereas if you develop your app with an open mind, then go back and add AP support you won’t cripple yourself.
Edit: I just remembered a couple examples (sort of). One was there was talk of a discovery mechanism that didn’t depend on webfinger, but Mastodon rejected it because they wanted to maintain backwards compatibility with gnu social (so they could bootstrap their userbase that gave them their influence).
Another was they almost didn’t include sharedInbox in the spec because Mastodon didn’t want to use it and thought it was stupid or evil or something. Luckily it still made it in but the compromise was that it was optional, putting extra burden on all other servers to support sending separate copies to every single user’s inbox.
Thank you for all the context! Fully agreed on basically everything, esp. that there’s always going to be some fragmentation. Still happy that we were able to limit that substantially. 🙂
Some more context I just remembered (funny how things come in waves):
Notice that I always say Mastodon devs and don’t name particular people. Part of that is out of respect and to keep it from seeming personal, but another important thing is that there were several Mastodon devs involved in the committee.
So when I say that there was a clear majority that means several Mastodon devs had a vote and they still lost.
But what happens in committee is people are allowed to argue for or against motions. At times, there would only be one person willing to argue on one side while several Mastodon devs would argue on the other.
So even if there was a majority vote numerically, there was a larger perceived dissent that would prevent motions from passing.
One chair was more affected by this than the other but again out of respect I won’t say which.
This is important to understanding why standards committees sometimes have undesirable outcomes. It’s also one of the reasons why sometimes groups committee shop and prefer W3C or IEEE or any of the others.
Standards committees is actually one of
humanity’ssociety’s biggest unsolved problems. 🙃Thank you for the very detailed answer!
I’m not sure if it’s the same thing, but I recall a Gab developer justifying their removal of federation in 2019, one of the reasons being that malicious actors were spinning up fake instances with thousands of users to make a server send separate copies of a message to every single user’s inbox, slowing the site down. Would shared inboxes help to prevent this type of attack, or is it something else?
Indeed. Making sharedinbox a requirement would mean that a server could simply refuse to do it the other way and then be immune from that attack. But because it is optional, all servers must then be vulnerable to this attack.
It can be mitigated by batching, and delivering say only 5 copies to one server at a time, but that would have to be very carefully crafted to not cause queue backup for other messages.
The ultimate workaround is queueless delivery, but there will still always be some penalty of having to keep revisiting a particular server.
A malicious actor can also deliberately slowly respond to deliveries, forcing the sending server to keep many sockets open.