> The instance must not monetize their users’ data without their informed consent or monetize the data of other users on the Fediverse without their informed consent

Lol, appreciate keeping an open stance but, there's zero chance Meta will resist farming the fediverse for data and profit. Sounds like federation is (thankfully) DOA just on this single principle

I read it that way too but I wonder if a finer line could (should?) be drawn than just “defederate for-profit instances”.

Due to the nature of ActivityPub, any monetization would be limited to Threads’ own users plus any public posts from other instances. They can’t (I believe) monetize our viewing habits for example.

This isn’t very different from a search engine indexing a post and showing ads in search results that include your post?

Right. It's not clear at this point, but f you boost my post and somebody on Meta is following you (if that turns out to be possible) then my post goes to them without my informed consent (unless I've defederated from them, or am on an instance that's defederated from them and is running authorized fetch). And if you reply to my post then your post -- with my account name and whatever you've quoted -- goes to Meta, no way to block that. (1/2)

@realitythreek @hachyderm

And they can easily link jdp23 to my real name (it's my handle on Twitter as well). So then they, or whoever runs ads, can use that info to target me on other non-Meta, non-Hachyderm sites.

At least, that's probably the case with today's software, depending on how they implement it. The @thenexusofprivacy post in their statement goes into it in more detail (although it's a draft, nore for instance admins and security folk -- it needs a summary at the top)

@captdust @realitythreek @hachyderm

Joining in here: this analysis is exactly why have the criteria that an instance cannot monetize their own users without consent OR cannot monetize remote users without their consent.

To be clear, explicit consent is core to our ethos. Everyone involved must be able to consent, or we will need to defederate to protect our users' right and ability to consent (as well as anyone that same for anyone federating with us).

💯. I was delighted to see that in your criteria! It, as well as the other aspects of user safety. And, "today's software" is a moving target -- and there may be well be a chance to influence the agreement Meta asks instances to sign. So it's very valuable to get these criteria out there, and I hope other instances considering federating are also considering and communicating what their criteria are.

@captdust @realitythreek

In general there are two distinct reactions to #Meta:

1) no way, no how -- either because of their history, the strong presence of anti-trans and racist groups on #Threads, belief there's no way to mitigate threats, or whatever. #FediPact is an example of this.

2) acknowledging all those issues but weighing them against potential upsides and considering what criteria make sense. Yours is one of the best-thought-out examples of this I've seen so far.

@captdust @realitythreek

This conversation is vital to the development of some sort of consensus as to how we as a community are going to continue to co-exist if and when instances begin to federate with #Meta.

The "relay" issue that Jon raises should be explicitly addressed. That is, if you federate with #Threads and do not enable auth_fetch it seems like posts that your user's boost will be sent to Meta (See https://mastodon.online/@mastodonmigration/110622589366603128).