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.
Sure, they could still make a change that intentionally breaks compatibility, but why would they?
This is the kind of naivety that gets us deepthroated.
If they’re “definitely not going to” then they don’t need the power to, yes? They should agree to our terms.
No one who’s here is going to leave just because the Threads users are gone.
I’m only here, specifically here, because communities I liked on Reddit pulled me. Granted, I like it here, but no platform is worth more than its content. If people get used to threads and threads leaves, people will leave with threads.
Yeah, that’s great when it’s a coalition of roughly equal platforms. What happens when a platform thousands of times the size of the others starts making demands?
I don’t see why the size of the user-base matters here. Why would Lemmy’s developers feel the need to implement these hypothetical reactions just because Threads does? Why would Mastodon? They’re not making demands, they’d be making changes just like everyone else. Everyone else could choose to add support for reactions or not. Things would still function without them.
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.
This is the kind of naivety that gets us deepthroated.
If they’re “definitely not going to” then they don’t need the power to, yes? They should agree to our terms.
I’m only here, specifically here, because communities I liked on Reddit pulled me. Granted, I like it here, but no platform is worth more than its content. If people get used to threads and threads leaves, people will leave with threads.
Yeah, that’s great when it’s a coalition of roughly equal platforms. What happens when a platform thousands of times the size of the others starts making demands?
I don’t see why the size of the user-base matters here. Why would Lemmy’s developers feel the need to implement these hypothetical reactions just because Threads does? Why would Mastodon? They’re not making demands, they’d be making changes just like everyone else. Everyone else could choose to add support for reactions or not. Things would still function without them.
Ah, so kind of like how one would filter out unwanted messages on a Kafka topic? Makes sense