Is it possible to automatically subscribe to all (federated) communities with the same name?

Example in the screenshot: I want to follow !astronomy, and I don’t really care whether the content is coming from from Lemmy.World, kbin.social and mander.xyz - I just want to see it all.

Obviously I could manually subscribe to them all, but is it possible to do so automatically? Ideally if a new similar community pops up on another instance, I wouldn’t miss it.

I read here that community grouping is a thing, so that instances with identical communities can work together. Is that a feature that could work towards this end?

  • Odusei@lemmy.world
    45·
    1 year ago

    Registering to all instances with the same username/password is just asking for trouble. They’re not all equal and some of them will get hacked somehow.

    • Cr4yfish@lemmy.world
      121·
      1 year ago

      Very good point! I think @TheButtonJustSpins@infosec.pub has a good idea on how to circumvent that.

      I could make my own database with hashed passwords using postgreqsl and RLS, which is pretty secure. The User then decrypts the hashed passwords once on login and is simultaneously logged into multiple instances of Lemmy to get the JWT of each instance, which is then stored in SessionStorage or even in a Cookie if the User wants to which would make this a one-time process.

      On signup the User could just register to one instance and then I just generate random 32 Character passwords and hash them with the Users’ password, then get the JWTs and if cookies are enabled the that would only have to be done every year or so (or when the User deletes the Cookies).

      This whole process is seems pretty easy, especially if you’ve done something like this before and I’m betting some other App Dev is already taking notes lmao.

      Edit: Let’s also do a thought experiment on what data will be leaked if I did this 1:1 and the database gets somehow hacked:

      For each User:

      1. Username (=> Gives away that you use Nemmy)
      2. Hashed Passwords (=> Hashed passwords cannot be read if you don’t have the original Users’ password until we have access to quantum computers which can literally crack the encryption algorithm)
      • siriuslyred@lemmy.world
        2·
        1 year ago

        How are you hashing a password with a random 32 character string? I feel like you are mixing terms here or so you combine the password and the random element first or do you mean you decrypt the hash with a symmetric algo and get the 32 char string?

        • Cr4yfish@lemmy.world
          21·
          1 year ago

          Ah, sorry if I’m being unclear.

          I was thinking of combining the user’s original password with a random 32 Character string and hash that combination. So basically salting the User’s password with random strings. That should work out to multiple passwords I can use.

          Thinking of it bcrypt does exactly this, so just running bcrypt a couple of times should be sufficient, no?

          Security wise if there was a breach, an attacker would still only have a couple of hashes, none of which are the original password and they can’t dictionary attack due to bcrypt.

          Also, if an instance was hacked, the worst case would be that the attacker gains access to the hash (if the instance stored passwords in plain text and didn’t also hash them themselves).

          I’m really tired right now so maybe none if this makes any sense, but I think it does lol.