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?

  • Cr4yfish@lemmy.world
    link
    fedilink
    arrow-up
    3
    ·
    edit-2
    1 year ago

    I’m making an App for Lemmy and I’m planning on adding that feature. I also want to make it so you only have to register once and the App can register you to all the instances you choose automatically.

    Edit: The Webapp is Nemmy, also the Community [email protected]

    Edit2: Please note that Nemmy is early Alpha, so not really useable as a daily driver yet.

    Edit3: Changed Community link to proper format

    • Odusei@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      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
        link
        fedilink
        arrow-up
        0
        ·
        edit-2
        1 year ago

        Very good point! I think @[email protected] 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
          link
          fedilink
          arrow-up
          0
          ·
          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
            link
            fedilink
            arrow-up
            0
            ·
            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.

  • Kichae@kbin.social
    link
    fedilink
    arrow-up
    0
    ·
    1 year ago

    Being able to one-click subscribe to all communities with the same name known by one’s instance is a frequently asked for feature, so I can see it coming down the pipeline, but no, it’s not a thing yet.

    Even short of that, though, it would be really nice if the community search page had subscribe/unsubscribe buttons right there in the search results. It would at least make it easier.

    • DrQuint@lemmy.world
      link
      fedilink
      arrow-up
      1
      ·
      edit-2
      1 year ago

      Subscribing to all would be a really good step already.

      But we all know what we all really want, ultimately, is to also then see all those subscriptions as a single feed, instead of having to visit all of them in order.

      What was one subreddit is now multiple. Something as small as 5 subs can be something as big as 20 communities here, and if one topic becomes big, then all subs of that topic will dominate your dashboard. Grouping up communities would be a way to tell the dashboard to not overload us on one pf the things and also to give us a way to browse just the one topic you want at the moment.

    • mookulator@lemmy.worldOP
      link
      fedilink
      arrow-up
      0
      ·
      1 year ago

      The other way to go is to automatically cross-post across federated servers if they have the same community. Why doesn’t it work like that?

      • wjrii@kbin.social
        link
        fedilink
        arrow-up
        0
        ·
        1 year ago

        I think the specific way that Lemmy/Kbin are growing is not exactly how the creators, particularly the Lemmy devs, envisioned it. I think they believed people of a specific interest or ideological leaning would band together on an instance, make a few communities that were relevant to them, and federation would allow their work to be shared and for them to venture out to participate in whatever they thought was neat. The best examples I can think of off the top of my head are probably Lemmygrad and the Star Trek instance that hosts three communities related to Star Trek (memes, general discussion, and deep-dive nerdery). I think the notion (I doubt it was a fully formed plan) was that instances would have relatively little overlap in the types of communities, and even less in the content.

        How growth is actually happening is seems to be turning out fairly differently. Reddit is basically having these little spasms (or maybe just coughs at this point) where a few thousand people leave at once, and many of them are heading to L/K instances. Sometimes we don’t quite fully understand federation when we arrive. Sometimes federation is down for a bit. People are basically flocking to established but previously tiny general instances with no particularly strong agenda, and seem to be creating communities with no particular concern about fragmentation.

        This may not have been how federation was envisioned, but it creates its own kind of flexibility, where instead of X% of communities being at risk when an instance goes dark or goes crazy, it’s Y% of content. I think giving users the option to adapt to this state of affairs by implementing something like persistent multireddits we could subscribe to or just a setting to “autocollate” identically named communities would be really helpful, eventually. In the meantime, trying to understand how we got here makes it easier to accept where we are, and hopefully lets me stay on the right side of the line between being a valued user and a pain in the ass, LOL.

        • BullsOnParade@lemmy.world
          link
          fedilink
          arrow-up
          0
          ·
          1 year ago

          I’m not sure if it’s for the same reasons, but Andro.id is another example of an instance around a common intent/subject, with communities based on topics within that subject area.

          Interesting concept but agree that if that was the intended means of propagating the fediverse, it doesn’t seem like it’s happening as planned (but still in a very viable way).

          • blakerboy777@lemmy.one
            link
            fedilink
            arrow-up
            0
            ·
            1 year ago

            I kind of wonder if we’ll see more interest focused instances continue to be a relatively regular occurances. I could see communities around specific games deciding to make a new home for themselves if for no other reason than everyone gets a new @myfavorite.game handle and you can customize a little more to their tastes. I think it might still lean more heavily towards generalized instances but maybe the main reason to run a new instance will be to be interest focused.

      • NotAPenguin@kbin.social
        link
        fedilink
        arrow-up
        0
        arrow-down
        23
        ·
        1 year ago

        Because they are not the same communities. Think of them as different subreddits about the same topic, like reddit has r/gaming r/games r/pcgaming and so on.