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.

  • GenderNeutralBro@lemmy.sdf.org
    link
    fedilink
    English
    arrow-up
    5
    ·
    10 months ago

    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. :)

    • psud@lemmy.world
      link
      fedilink
      English
      arrow-up
      2
      ·
      10 months ago

      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