thenexusofprivacy

Meta is a company whose business model depends on exploiting the data it gathers, and its privacy policies are carefully written to give it as much flexibility as possible. It's true that if you're on an instance that federates with Threads you're assuming that risk. If you compare their language to a policy that's written with a goal of privacy -- like eu.social's the differences are clear.

Please stop putting words in my mouth.

OK, then, speak for yourself: do you see instances that federeate with Threads as being part of Meta's ecosystem?

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.

Today, I've gone to a lot of trouble to have fediverse accounts today, and accounts on other enviroments that aren't as toxic and hostile as Facebook ... I still have a Facebook account. It's necessary to keep in touch with some family members. It's valuable for activism -- meet people where they are. It's the best place to find out about music events. There are some friends and former colleagues that it's the best way to keep in touch with. etc etc I wish those things weren't the case, but they are. So I have an account but limit my engagement -- these days I rarely post except for activism, private messages, and occasionally resharing posts that people are trying to get the word out about. There's still a lot of value in keeping most of my activity off there.

And I still have a Twitter account despite all its issues. A lot of reproductive justice and abolitionist organizers are still there. It's better than any other social network for getting first-hand views of Palestinians. A lot of Black Twitter is still there. There are some friends and former colleagues that it's the best way to keep in touch with. It's potentially still useful for activism purposes. etc etc. So I have an account but limit my engagement -- these days I rarely post except for retweeting, DMs, and stuff that I don't care if it's public. There's still a lot of value in keeping most of my activity off there.

And some reproductive justice and abolitionist organizers have left Twitter and gone to Threads. Threads is likely to be useful for activism purposes. Over time there are likely to be friends and former colleagues that it's the best way to keep in touch with. I'm sure other etc etc's will evolve. So I have an account but limit my engagement. There's still a lot of value in keeping most of my activity off there.

And Meta's fediverse is likely to be useful for activism, and there are likely to be people there that I don't have any way to keep in touch with. Also, it's a great audience for The Nexus Today. I already have accounts there so don't expect to give them up. So I have an account but limit my engagement.

It's a classic double-bind. Being able to staying in an environment that some people find isn't safe enough to stay in is a form of privilege; but then again, feeling like I have to stay in an anti-LGBTQIA2S+ environment where I feel constrained as to what I can say publicly and my data's being exploited is a form of oppression -- and so is the expectation that I should have to give up on all these valuable things just because I want to spend most of my time in an pro-LGBTQIA2S+ enviroment. So, there aren't any perfect answers.

Yes, I'd say Lemmy communities are cross-instance communities - people can join communities on a different instance than their account.

For new instances, the easiest thing is to start with the list of an instance that the kind of moderation you agree with. If I were starting up an instance in the Lemmy world, I might go with the current federation list of lemmy.blahaj.zone or beehaw.org (although others might make differnet choices), in the Mastodon world I might use awoo.space as a starting point.

There's certainly a need for tools to make this more scalable. "Recommended lists" are a likely next step; there isn't much software support for this yet, but it's similar enough to blocklists that they're also fairly straightforward; it would be up to the new instance admin to decide how many to inspect or whether just to trust the list. And tools are also needed to address the challenge in the other direction: how do existing instances decide whether or not to accept the request? Instance catalogs like fediseer can help. Another possibility that I mention and link to in the article is "letters of introduction"; federations of instances (which I'll talk about in the next installment) are another.

You do realize that instances federating with Threads will share data with Threads, and that Meta's supplemental privacy policy specifically says that they'll use all activity that federates to meta for tracking and ad targeting, right?

So for example, if you're on an instance that federates with Threads, and somebody on Threads is following you, all of your posts -- including your followers-only posts -- will get tracked by Meta. Or if somebody who boosts your post and they've got followers on Threads, your post will be tracked by Meta. Or if you like, boost, or reply to a post that originated on Threads, it gets tracked my Meta. And these are just the most obvious cases. What about if somebody on an instance that's not Threads replies to a Threads post, and you reply to the reply? It depends on the how the various software implements replies -- ActivityPub allows different possibilities here. And there are plenty of other potential data flows to Meta as well.

Of course they're still just at the early stages of federation so it's hard to know just how it'll work out. Individually blocking Threads might well provide a lot of protection. But in general, instances which federate with Meta will almost certainly be tracked significantly more than instances that don't.

Today almost no instances run ads (misskey is as far as I know the only platform that's got support for ads) and Threads is the only one that does tracking. I'm using "free fediverses" the way https://freefediverse.org/index.php/Main_Page does -- instances that reject federation with Meta.

Thanks! I included a slightly-modified version of it in https://lemmy.blahaj.zone/post/7194307 , we'll see how it goes.

Got it, thanks much!

Great point, I should be more explicit in the article. On Lemmy, it would look like a couple of things:

• today, another instance's request to federate is accepted unless it's explicitly blocked. This means that bad actors can get away with stuff until they're discovered and blocked (although it makes it easier for good actors to federate). Consent-based federation turns that around: a request to federate isn't accepted unless it's approved. One way an instance admin could decide whether or not to approve a request is to look at FediSeer to see what other instances are saying about the requestor.

• at the individual level, it would mean that people would start out by participating in local communities (and maybe even just seeing posts from their instance, not sure about that), and could then choose to have their posts federated out

This is great, thanks so much for taking the time to do it! I've been thinking of moving my Ghost blog/newsletter to Wordpress to take advantage of the fediverse integration, and one of the things that was holding me back is that I couldn't find a post like that that also includes the plugins and recommended settings.

I'll be importing my content (there are various utilities to turn the Ghost JSON export into an importable XML file). Any idea of that imported content will federate, or will it just be treated like old blog posts and not federate?