this post was submitted on 14 Jan 2024
708 points (100.0% liked)

196

16552 readers
1616 users here now

Be sure to follow the rule before you head out.

Rule: You must post before you leave.

^other^ ^rules^

founded 1 year ago
MODERATORS
708
submitted 10 months ago* (last edited 10 months ago) by spujb@lemmy.cafe to c/196@lemmy.blahaj.zone
 

see if your instance is one of them here: https://fedipact.veganism.social/

you are viewing a single comment's thread
view the rest of the comments
[–] atocci@kbin.social 14 points 10 months ago (2 children)

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.

[–] yukijoou@lemmy.blahaj.zone 9 points 10 months ago (1 children)

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

[–] atocci@kbin.social 3 points 10 months ago (1 children)

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.

[–] bitwolf@lemmy.one 1 points 10 months ago

Ah, so kind of like how one would filter out unwanted messages on a Kafka topic? Makes sense