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.
However, XAMPP didn’t just die because it opened itself up to Microsoft and got extinguished
So, we went from the somewhat imaginary “google killed xmpp” to fully fictional “Microsoft killed xampp” now? it’s almost like the fedipact people literally have no clue what they are talking about.
Yeah all the EEE/“Threads will kill us” talk reminds me of how Slack killed IRC by first offering an IRC gateway, and then killing off support. And after that IRC literally died.
/s
I saw a post here about how Threads’ biggest enemy at this point is antitrust, and a federated approach is a clever way around that. I think that makes much more sense than the EEE narrative.
Zucc is using us to skirt regulations
Yeah, that aint any better. Defederate and let them die.
Who was this article written by?
This excerpt seems like pure misunderstanding in communication, or a typo.
None of us are actually claiming ridiculous things like “Microsoft killed XAMPP”. It’s obvious that this is a communication error or typo (see: similarity in spelling of XAMPP and XMPP)
Yeah sorry. That was a mistake but I changed it now :)
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?
What is the Fedipact?
A group of people who want to stop private companies from running lemmy/mastodon/etc instances.
Not private companies. Abusive megacorporations who absolutely don’t have good intentions.
There are plenty of private companies who wouldn’t face, well, really any pushback.
Stop strawmanning.
Nope, nobody wants (or even could) stop corps running instances. Fedipact is a number of instance admins (too few, in my opinion) that prefer to defederate their instances from those run by scummy Facebook and the likes. Some people is on the Fediverse specifically to avoid stuff managed by the Elons and the Zucks.
Cant activitypub make license such that one need to keep server open to be able to use protocol
Like a GPL for a protocol? You can’t really license a protocol. I think that would be patents.
And software patents are a bad idea.
So, in my opinion, no.
This is digging into pretty legal territory and copyright law is (arguably unnecessarily) complex – but licenses are things that you use to let people use your patents. I think that’s what they were initially and mainly; but then software and the copyleft movements kind of detached the concepts of licenses and patents.
The fediverse protocols could definitely be patented and licensed, but, like you said (or implied, really), that’s… sketchy af. Like, anyone we could trust to patent it would probably refuse to do it – Linux Torvalds would probably curse me out for even suggesting it, and the lecture rms gave me would probably never end.
Ohh so developer cant control who can use protocol?
