I like that option for our server, social.coop, and it's the one we voted to implement earlier this year.

We know that Threads already hosts bad actors (e.g., LibsOfTikTok). We know some reasonable folks have set up shop there and will continue to flee there from X.

This option makes it clear that Threads is not a safe space, while allowing limited connections.

Every instance will implement the option that makes sense to them, of course.

@thenexusofprivacy @eloquence
Hmm? Doesn't it do about the same amount to stop people's data getting to Threads?

Instance-limit stops Threads users following you without consent. Individually blocking Threads rejects them automatically, instead of manually.

*Neither* is documented as stopping Threads users from reading your posts. Even if authorized fetch is enabled.[1]

[1] I base this on https://hub.sunny.garden/2023/06/28/what-does-authorized_fetch-actually-do/

@thenexusofprivacy @eloquence
Clearly the Fediverse is not designed with consent at the forefront.

You can theorize about taking back privacy on public networks.

But if site A wants to allow Google, and you want to post a publicly readable reply on site A, my hope would be that you're educated and supported in knowing that you'll be Google-able.

E.g. if y'all want to roll back Google, that's a long-standing fracture. It needs work on *clear expectations* or you'll have nothing but fractures.

It's certainly true that the fedierse wasn't designed with consent at the forefront. But you're wrong about the effect of blockig and authorized fetch: sites that block Threads and turn on authorized fetch won't federate data to Threads.

It's true that Threads could technically still scrape public data if they want (and if other actions aren't taken to prevent them) but EU datra protection commissioners have warned them that scraping without consent is non-consensual access to data. And, data like followers-only posts and direct messages *isn't* public so isn't easily scrapable.

@sourcejedi @eloquence