Thanks!

Thanks for making the effort to research it ... there are some great examples in this thread and some of the cross-posts (although some were so egregious that the mods took them down). Also, did you follow the links at the beginning of the article? They're talking about Mastodon (I'll include some examples from Lemmy in the revised version) but give an idea o the overall dyamics. In any case, I'll put in a big more about the problem in the revised draft.

Thanks, glad you think they're reasonable. I don't see it as using ActivitiyPub implying consent; it's more that ActivityPub doesn't provide any mechanisms to enforce consent. So mechanisms like domain blocking, "authorized fetch", and local-only posts are all built on top of ActivityPub. I agree that many people want something different than ActivityPub currently provides, it'll be interesting to see how much the protocol evolves, how far people can go with the approach of building on top of the protocol, or whether there's shift over time to a different protocol which has more to say about safety, security, privacy, and consent.

Thanks! Here's how it looks:

Agreed that there isn't one particular model that's right or wrong for everybody, and that a split is likely -- a region like today's fedi and that welcomes Threads, and a more safety-focused region (with more blocking, a more consent-based federation).

I had shared the draft version here a few weeks ago, and this incorporates some of the feedback -- including "This goes against everything the Fediverse stands for" 😎

It's true, but the time pressure is likely to be used to try to get a weak "compromise" bill through.

Yes, at least on Lemmy. It's the icon with two boxes.

Fediblockhole does something along those lines for on Mastodon ... not sure if there's an equivlaent in the Lemmy world.

Yes, you described what you see as the difference between data and "data" clearly. And I described what I see as the implications clearly. If anybody's still reading the thread, they can make their own conclusions.

It’s less of an agreement and more of a protocol.

Threads Supplemental Privacy Policy begs to differ that there's not an agreement here.

My point is that defederating from meta doesn’t stop meta from tracking you online.

I never claimed it did. It eliminates one path of consensually sharing data (or "data", in your terms) with Meta.

In terms of your list, my perspective is that a server that federates with Threads is part of Meta's ecosystem -- #1 in your list. You don't seem to see it that way, and that's what we're not going to convince each other about.

𝕯𝖎𝖕𝖘𝖍𝖎𝖙: If those instances choose to share data with Threads, you should not join those instances.

Also 𝕯𝖎𝖕𝖘𝖍𝖎𝖙: Federating with threads shares “data” in the form of content

I appreciate all the time and energy you're putting into the comments here, but what it comes down to is that you're not concerned about the difference between the federation scenario -- where this data is given to Threads under an agreement that explicitly consents to giving Meta the right to use the data for virtually whatever they want -- and the situation today -- where Meta and others can do the work to non-consensually scrape public data on sites that don't put up barriers.

We're not going to convince each other, and we've both got enough walls of text up that at this point neither of us are going to convince people reading the thread who aren't already convinced, so let's save ourselves the time and energy and leave it here.

In the short term, they'll be much smaller than Meta's fediverse (because mastodon.social and most of the big instances are federating with Threads) and of course much smaller than Threads. Longer term, we'll see, but I wouldn't expect them to be as big as Threads for a long time if ever.