I'm changing my stance on the whole Meta/project92 thing after reading this article. I think the entire* fediverse should block project92 by default. Later, some instances can re-evaluate whether to maintain those blocks, once we have a better idea of what the benefits and consequences of federating will be:
Of course, it's possible to work with companies you don't trust. Still, a strategy of trusting the company you don't trust until you actually catch them trying to screw you over is ... risky. There's a lot to be said for the approach scicomm.xyz describes as "prudently defensive" in Meta on the Fediverse: to block or not to block?: "block proactively and, if none of the anticipated problems materialise within time, consider removing the block." Georg of lediver.se frames it similarly:
We will do the watch-and-see strategy on our instance in regards to #meta: block them, watch them, and if they behave (hahahahaha) we will see if we unblock them or not. No promise though
Previously, I'd thought "some block, some federate" would be the best approach, as described in this post by @atomicpoet:
My stance towards Meta is that the Fediverse needs two types of servers:
Lobby servers that explicitly federate with Meta for the purposes of moving people from Meta to the rest of the Fediverse
Exit servers that explicitly defederate with Meta for the purposes of keeping portions of the Fediverse out of reach from Meta
Both approaches not only can co-exist with each other, they might just be complementary.
People who use Meta need a way to migrate towards a space that is friendly, easy-to-use, and allows them to port their social graph.
But People also need a space that’s free from Meta, and allows them to exist beyond the eye of Zuckerberg.
Guess what? People who use Meta now might want to be invisible to Meta later. And people who dislike Meta might need a bridge to contact friends and family through some mechanism that still allows them to communicate beyond Meta’s control.
And thankfully, the Fediverse allows for this.