For those who aren’t aware, Kbin Cafe is a Kbin instance I run. Cross-posting our stance on Threads for visibility.
As Meta’s new App Threads has now launched, it’s important that I definitively state our stance on blocking federation with Meta if they choose to adopt ActivityPub:
Kbin Cafe will not be preemptively fediblocking Meta. However, I’ll be keeping a close watch on the situation as it unfolds, with my finger hovering over the block button. My first priority is the integrity and safety of the community, and with this in mind there won’t be any second chances given to Meta–their first strike results in a block.
Efforts are being coordinated by @tchambers and others to build out Fediverse test suites to ensure that all new actors (like Threads) that claim ActivityPub compliance have to prove their claims or be shown where they are lacking. That is the one real defense against “Embrace, Extend, Extinguish” plays by any large actor. To join in and help with this, follow this Frendica group here:
https://kbin.cafe/m/activitypubtestsuite@venera.social
This ActivityPub Test Suite needs to happen ASAP, so any dev support is welcome!
As always, feel free to comment here or message me with any questions or concerns.
I’d say any automated/integrated effort to direct users of federated instances to the threads site to view content should count as a strike. (Such as needing to go directly to the threads site to view an image that could be easily posted anyway.)
So should any automated/integrated effort to encourage users to make their own threads account. (Such as needing an account to visit this link or view this image.)
Any attempt to coerce non threads users to sign any sort of agreement or TOS with threads.
As well as any data collection on non threads users. Merely interacting with a federated threads account should not entitle meta to any data collection of that user.