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
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
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.
As a kinda layman, I am still flipping between kbin and lemmy(.world) alot, kbin also because it has no released mobile app (yet), and I just read a post complaining that kbin is missing a lot of content from lemmy, so there is definitely still “federation issues” there
From what I understand, stuff from lemmy won’t pop up in the All feed until someone subscribes to that sub from lemmy. It won’t just pull every post from lemmy on its own, it has to be requested. That isn’t a federation an issue, but an interest issue.
It doesn’t really matter what they use. As long as it’s open source and decentralized, avoiding big tech running the servers, it’s a huge win.
There is no peaceful existence with big tech when it comes to this. They will turn it into ads and tracking and that’s not compatible with the moral values of the open source community.
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
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
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.
As a kinda layman, I am still flipping between kbin and lemmy(.world) alot, kbin also because it has no released mobile app (yet), and I just read a post complaining that kbin is missing a lot of content from lemmy, so there is definitely still “federation issues” there
From what I understand, stuff from lemmy won’t pop up in the All feed until someone subscribes to that sub from lemmy. It won’t just pull every post from lemmy on its own, it has to be requested. That isn’t a federation an issue, but an interest issue.
A better analogy is how Lemmy and Mastodon are theoretically compatible. Yeah, you can get federated content, but it really isn’t usable.
Kbin is just a different implementation of Lemmy, intended to be compatible (not coincidentally compatible through the protocol).
It doesn’t really matter what they use. As long as it’s open source and decentralized, avoiding big tech running the servers, it’s a huge win.
There is no peaceful existence with big tech when it comes to this. They will turn it into ads and tracking and that’s not compatible with the moral values of the open source community.
It’s Microsoft culture vs Linux culture.