I don’t think so. There are tons of ActivityPub implementations out there already that don’t even support all parts of the official spec (Lemmy can’t display attached images, for example). There are also implementations that have tacked on additional functionality beyond the official spec (again, Lemmy’s downvotes).
It’s a very flexible protocol that allows developers to pick and choose what features they want to implement in their services.
There are tons of ActivityPub implementations out there already
but none are widely used by such a massive amount of people as threads, and especially people who don’t understand/care about spec compliance or even how federation works
honestly, i think in the best scenario, threads will create their own activitypub “fork”, and most instances won’t want to follow it, forcing the people who were on non-threads instances to chose between going to threads to keep in touch with their threads mutuals, or staying on non-threads instances and no longer having a reliable way of keeping in touch with those people.
worst case would be instances following what meta does and making them the spec dictators pretty much, the spec would become closed source and all other fedi implementations would lag behind in features compared to threads, and they can at any point change the spec and break other instances.
i think the point of defederating with threads isn’t just the defederation, but is about sending a message that we don’t want to play their game, we want to keep doing our things our ways. if they want to interract with the fediverse, they’ll have to play by our rules, we don’t want to follow theirs
There is an assumption that any changes or additions Threads may make to their implementation of ActivityPub beyond the official spec will break compatibility with other instances. It won’t though, that’s the point I was trying to make above.
Any additions they may want to make can absolutly be added on top of the existing official spec without breaking compatibility. Lemmy has downvotes but can still read comments and posts by Mastodon users. Mastodon users can post to Lemmy communities. You can see Pixelfed pictures on Kbin. Kbin posts can be read on Misskey. Misskey posts are visible on Mastodon.
All of these services have features that don’t exist elsewhere, built outside of the existing spec, but the core content is all interoperable. Anything Threads may want to add can be done without destroying spec compatibility. Sure, they could still make a change that intentionally breaks compatibility, but why would they? Theres nothing in it for them. No one who’s here is going to leave just because the Threads users are gone. The Threads users are already absent and we’re all still here.
I don’t think so. There are tons of ActivityPub implementations out there already that don’t even support all parts of the official spec (Lemmy can’t display attached images, for example). There are also implementations that have tacked on additional functionality beyond the official spec (again, Lemmy’s downvotes).
It’s a very flexible protocol that allows developers to pick and choose what features they want to implement in their services.
but none are widely used by such a massive amount of people as threads, and especially people who don’t understand/care about spec compliance or even how federation works
honestly, i think in the best scenario, threads will create their own activitypub “fork”, and most instances won’t want to follow it, forcing the people who were on non-threads instances to chose between going to threads to keep in touch with their threads mutuals, or staying on non-threads instances and no longer having a reliable way of keeping in touch with those people.
worst case would be instances following what meta does and making them the spec dictators pretty much, the spec would become closed source and all other fedi implementations would lag behind in features compared to threads, and they can at any point change the spec and break other instances.
i think the point of defederating with threads isn’t just the defederation, but is about sending a message that we don’t want to play their game, we want to keep doing our things our ways. if they want to interract with the fediverse, they’ll have to play by our rules, we don’t want to follow theirs
There is an assumption that any changes or additions Threads may make to their implementation of ActivityPub beyond the official spec will break compatibility with other instances. It won’t though, that’s the point I was trying to make above.
Any additions they may want to make can absolutly be added on top of the existing official spec without breaking compatibility. Lemmy has downvotes but can still read comments and posts by Mastodon users. Mastodon users can post to Lemmy communities. You can see Pixelfed pictures on Kbin. Kbin posts can be read on Misskey. Misskey posts are visible on Mastodon.
All of these services have features that don’t exist elsewhere, built outside of the existing spec, but the core content is all interoperable. Anything Threads may want to add can be done without destroying spec compatibility. Sure, they could still make a change that intentionally breaks compatibility, but why would they? Theres nothing in it for them. No one who’s here is going to leave just because the Threads users are gone. The Threads users are already absent and we’re all still here.
Ah, so kind of like how one would filter out unwanted messages on a Kafka topic? Makes sense