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.
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
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.
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
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.
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
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.