Imagine a world without platform lock-in, where no ban or billionaire could take down your social network. That’s what ActivityPub has planned.

  • tool@r.rosettast0ned.com
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    Honestly, this isn’t even necessary. The only thing that needs to be implemented is federated authentication, because then you could log in to any instance with one set of credentials. Since the content you post/comment is already replicated locally on other instances, you wouldn’t even need to import/export anything, it would already exist on the other instances.

    Implement federated user authentication and you’re golden.

    • mkhoury
      link
      fedilink
      arrow-up
      1
      ·
      edit-2
      1 year ago

      How would federated authentication help with an instance sinking and having to port/rebuild a profile?

      • tool@r.rosettast0ned.com
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        Maybe I’m misunderstanding (and that’s certainly a possibility because I’ve been on Lemmy for barely a week), but wouldn’t the profile be rebuildable since the content generated by the user has been replicated to other instances?

        If that is the case, the only thing that’s missing is federated authentication so the user can log in to any instance with a single set of credentials.

        • mkhoury
          link
          fedilink
          arrow-up
          1
          ·
          1 year ago

          From what I understand of federated authentication, your instance needs to be up to authenticate against. This doesn’t help if your instance goes down. Did you have some other mechanism in mind?

          • tool@r.rosettast0ned.com
            link
            fedilink
            arrow-up
            1
            ·
            1 year ago

            That’s correct. The solution would be either:

            1. Centralize authentication and nothing else
            2. Replicate password hashes & salts to all instances

            #1 would absolutely be the most preferable. There are two possible snags with option #1: sdfsdf

            • You’re introducing a small element of centralization into a decentralized platform
            • The admins of the centralized authentication server must be competent and trustworthy

            Cost wouldn’t really be a factor for this solution and could easily be sustained from donations, you’re not going to be getting a huge amount of traffic from authentication requests.

            I included option #2 for the sake of completeness. This would work, but it isn’t the best idea from a security standpoint. The risk can be greatly mitigated with good password requirements and the use of a strong password hashing algorithm like Argon2/bcrypt/PBKDF2/etc in combination with salting the hash. A quick look at Lemmy’s code shows that they’re already hashing passwords with bcrypt, so that requirement is met, but it doesn’t look like they’re explicitly salting it. That doesn’t really matter too much in this scenario with that algorithm though, since it’s going to be salted automatically anyway. Lemmy’s code also shows that it’s using bcrypt’s default cost value (10 rounds), so it would take thousands (to millions) of years to crack the hash if you have even the most basic password requirements in place. If you add the option to put MFA in front of that, you’ve almost removed the risk entirely, as it won’t matter in the very unlikely event that the password actually is cracked, because it’s useless without access to the second authentication factor.

            So yeah, there are a couple of ways to do it, and each have their downsides/tradeoffs, but the level of difficulty/effort to do it is not very high in either case.