What are you thoughts about this?
This was a good read and it’s something I’ve wondered about. The fediverse is sorta built on this promise that everyone will be able to interact across any implementation of ActivityPub.
But that’s not really true. The different types of social media have wildly different implementations, where we have to rely on developers communicating and cooperating with other implementations for everything to work even a little bit
Yea probably similar to how Lemmy and Kbin are theoretically compatible. ActivityPub doesn’t guarantee that, it’s only because they happen to use ActivityPub in the same way. If one of them changes their implementation, compatibility breaks.
I do often wonder how much it matters that all these platforms use ActivityPub
If one of them changes their implementation, compatibility breaks.
And that’s why you want a healthy spread of users across both (and even a third one, one day) platforms. That way they have to keep compatibility with each other to not lose a major share of the userbase
You’d also break compatibility with the previous version of your software, so your users wouldn’t be able to see any threads posted on any server that wasn’t updated.
If you had a really good reason to make this change, chances are this reason would apply to both services and they would move together. If either developer does it out of spite, nobody is going to upgrade their instance and the project would be forked.
And if they were the type to break ActivityPub integration of their service out of spite, why would they use it in the first place? It just makes no sense. I’m not particularly worried.
I think it might be good to create specific protocols in the ActivityPub documentation for the various types of social media to ensure interoperability.
No hard rules, but a guideline for how to ensure you are maximizing compatibility, maybe.
There at least needs to be some extensions. I’m thinking of methods of secure migration (both instance: domain to domain and user: instance to instance) and a method for adopting a community that existed on a now offline instance.
In about a year we’ll probably have that anyway. Practices like that will emerge as people get more experience running fediverse servers, and then they’ll get adopted by people trying to do what’s known to work
Well, one thought is that this blog post is from January 2019, and that a lot has changed since then. Among them is that a lot of different ActivityPub implementations have become a lot more mainstream than Diaspora.
The author’s stance might of course not have changed, but it seems to me this post is a bit too outdated to enter into a current discussion. Interoperability between ActivityPub services is working fine, at least in my opinion.
I wonder what would he think of the Nostr.
Just off the top of my head, my initial reaction is that it really seems like activitypub is just not suitable for implementation as the base layer in diaspora.
Or at least it wasn’t four years ago
I might have to look at ActivityPub after this. I mean I saw framework mentioned enough where it sounds like we should have built something using ActivityPub as a framework to ensure compatibility in the fediverse. Or am I reading that wrong? Very interesting article. I would expect we all need to get comfortable with changing and questioning things if we want to build something truly decentralized and truly connected.
We did build stuff on ActivityPub: Lemmy, Kbin, Mastodon etc. are all based on that underlying protocol.
