Asklemmy

In my opinion, "watch and see" is a good approach towards potentially hostile entities. Meta is not "potentially" hostile - it is a hostile entity already, due to its backstory of EEE (embrace, extend, extinguish), and it should be told to fuck off right off the bat. It will not contribute with the Fediverse in the long run.

Their strategy is potentially along those lines:

1. Create its own instance (let's call it "Metadon"). Play by the rules at the start. Get a rather large userbase.
2. Introduce policy, code, and monetary changes to Metadon; things that don't piss off the users, but make it harder for admins of other instances, that'll need to either play along or defederate Metadon. Over time smaller instances will bleed to death, with Metadon absorbing their userbases.
3. Once Metadon controls a good chunk of the Fediverse, it pulls off the plug, because it's now in a position to piss off the userbase to further Meta's goals. "We're going to defederate everyone else for protection of the users. Think on the children!" Then it starts reintegrating into Facebook and WhatsApp, including crap like "you need a Faecesbook account to use Metadon".

And we can't really rely on "everyone doing the right thing", because most people won't. Cue to the users still using Reddit because they don't care about things in the long run; it would be the same here, plenty users will use Metadon if it throws them a big enough of a bone.

simple, don't federate with meta

Copyleft should absolutely work. Not sure what we are currently doing, but nearly every toot or reply in the fediverse is copyrighted content. You must explicitly or implicitly give a license to every instance to use and redistribute that content. I could imagine a field in ActivityPub that declares the license, for example using Creative Commons licenses. If this license forbids commercial use, Meta can't use it. Also nobody else, such as journalists? Probably needs more thought on how a license should work. It is definitely a sharp sword!

I'm concerned enough to message the admins of my instance if I knew how. I came here to get away from corpos, not to have them follow us here. They need to go back to their walled gardens and stay there.

I personally think the proper approach is to limit them to one instance. If they suddenly start trying to distribute a Meta "easy setup" variant of their server or something such that anyone can set up a Fediverse Meta-based server, that's where the line should be drawn. That does have the potential to run an EEE play.

However, if everyone from FB wants to be able to subscribe to Mastodon or Lemmy content from their FB account, that's not nearly as big a deal to me assuming they all come from @facebook.com or whatever. Because worst case, people just block that one server and their embrace is over.

This is not the issue you should be scared of.

You should be scared because every terminally online non-technical person you know ALREADY has a Thread account.

Here’s the way it will go down:

• Thread federates
• Users complain it’s too hard to remember the @mastodon.social vs @thread.meta or whatever
• Meta removes requirement for Thread users to have to do that within Thread when mentioning for searching other Thread users
• Thread users complain to users outside Thread that it’s annoying they have to “be that way” and they should “just use Thread to make it easy, dude”
• at the same time Many instances defederate with Thread
• Thread adds “Megaheart” superlike feature that adds a sticker with an animation to someone’s “prick” (what do they call posts over at Thread anyway?)
• Users on Thread complain that they can’t superlike users from other instances
• Users from other instances get sick of their complaining and move to Thread’s instance
• Important business and service accounts move to Thread to “ensure comparability and availability”
• Thread defederates from the larger network, having captured all the important content that people find useful
• The rest of the fediverse remains mostly people posting about the fediverse, how to host their own instance, and arguing about how to move forward on an increasingly fruitless-seeming open source project.

( - in 2032, Thread decides to charge for API access, citing “freeloading app developers who have been profiteering off their hard work”)

Policies won't stop them.