Embrace, Extend, Enforce (ƎƎƎ): A practical Strategy against potentially abusive Instances like Meta’s Threads
Embrace, Extend, Enforce (ƎƎƎ): A practical Strategy against potentially abusive Instances like Meta’s Threads
TL;DR: The common view on Meta’s Threads is that it will be either all good or all bad, leading to oversimplified and at the end contra productive propositions like the Fedipact. But in reality, it…
cross-posted from: https://lemmy.ca/post/12225995
cross-posted from: https://lemmy.ca/post/12225991
TL;DR: The common view on Meta’s Threads is that it will be either all good or all bad, leading to oversimplified and at the end contra productive propositions like the Fedipact. But in reality, it’s behaviour will most likely change dynamically over time, and therefore, to prevent us getting in a position, in which Threads can actually perform EEE on us, we need to adapt a dynamic strategy as well.
You're viewing a single thread.
There's another way that Threads could gain an advantage, and that is by releasing fediverse software that is really great that people want to use, but that the community has no control over and is released with a restrictive license. This software could provide advantages in local resource and network efficiency, instance management, ease of configuration, ease of upgrade, etc, which would be appealing to people who run instances. Once that software has a big enough share, they could begin introducing changes that suit them and not the community. If ease-of-upgrade is in place, and not enough transparency from meta about the included changes, folks could end up unwittingly adopting bad features, perhaps ones that put them in legal peril and jeopardize their ability to continue hosting the instance. If this software doesn't have easy data export features, then migrating the instance to new software could be an insurmountable task.
I think we should all be incredibly critical of any community and systems maintenance challenges in software released by meta, and be diligent about testing migrate-away scenarios. In fact, I would say that if they do release self hostable software, we make sure to port all the good features to FOSS software as quickly as possible. We don't want to end up in a legal bind by adopting source-available software that is not free-as-in-freedom.
and be diligent about testing migrate-away scenarios
I think this is the most important thing, and sadly, it's not addressed very well by the current fediverse platforms (e.g. Mastodon, Lemmy, Kbin) because it is indeed a difficult problem to solve.
I'm aware that Mastodon has an account migration scheme, detailed here: https://docs.joinmastodon.org/user/moving/ . However, it's kind of clunky. It involves making a new account, then posting a redirect notice and optionally a "move" event that will automatically make your followers (if they have a compatible client/platform) unfollow the old account and follow the new account. There's no mechanism to move posts.
Lemmy has no migration feature whatsoever as far as I know.
Email has no migration feature.
A common anti-feature of all of these platforms is that your instance owns your identity. If you want to change instances, you need to create a new identity and try to inform the world of the change somehow. Even integrating tools to make the "informing the world" part easier, like Mastodon, does not solve the underlying problem. If your instance suddenly goes offline, your identity goes with it. Your identity can be "held hostage" by the instance admins. Your access can be arbitrarily revoked by the instance admins. Your account security is entirely outside your control.
That's the core problem here: your identity is controlled by a third party, not by you. If the instance bans you, shuts down, or is compromised, you lose access to your identity entirely.
OAuth can help with some of this by decoupling the identity from the application/instance, but then you are still at the mercy of your identity provider (IdP). You still do not own your identity.
So what's the solution? Honestly, I don't know enough about cryptography to say. Cryptography is hard. But I feel like a distributed web of trust using public/private key pairs a la GPG should be viable if you build a robust protocol around it. Instead of your canonical ID being user@instance, it would be a public key, which would then be signed by any instances you choose, according to each instance's own rules. A public key could be associated with any number of human-friendly names (e.g. user@instance1, user@instance2, etc.) which would all map back to the same public key in a distributed account database. Since only YOU control the private key, you could maintain your identity even if your instance unexpectedly went offline, and you could proactively build trust across a wide variety of instances to minimize that impact. If an instance goes rogue and de-validates users willy-nilly, other instances will be able to see that and adjust their trust accordingly.
I look forward to someone smarter than me telling me why that's stupid. :)
It's stupid as normal people don't want to manage crypto keys, it would be fine under an app where it's all invisible to the user, but many use Lemmy from the web
That's a good point. I could imagine Meta will try kind of a "franchising" of the Fediverse. With many little Threads-instances popping up that are not maintained by Meta itself but give it a fee for their software.
I think we should all be incredibly critical of any community and systems maintenance challenges in software released by meta, and be diligent about testing migrate-away scenarios. In fact, I would say that if they do release self hostable software, we make sure to port all the good features to FOSS software as quickly as possible.
Sounds like a good point although I'm not really in the opensource community to know how the dynamics are. Is it a threat scenario that is common and doesn't this already fall under EEE?