Perhaps I’ve misunderstood how Lemmy works, but from what I can tell Lemmy is resulting in fragmentation between communities. If I’ve got this wrong, or browsing Lemmy wrong, please correct me!

I’ll try and explain this with an example comparison to Reddit.

As a reddit user I can go to /r/technology and see all posts from any user to the technology subreddit. I can interact with any posts and communicate with anyone on that subreddit.

In Lemmy, I understand that I can browse posts from other instances from Beehaw, for example I could check out /c/[email protected], /c/[email protected], or many of the other technology communities from other instances, but I can’t just open up /c/technology in Beehaw and have a single view across the technology community. There could be posts I’m interested in on the technology@slrpnk instance but I wouldn’t know about it unless I specifically look at it, which adds up to a horrible experience of trying to see the latest tech news and conversation.

This adds up to a huge fragmentation across what was previously a single community.

Have I got this completely wrong?

Do you think this will change over time where one community on a specific instance will gain the market share and all others will evaporate away? And if it does, doesn’t that just place us back in the reddit situation?

EDIT: commented a reply here: https://beehaw.org/comment/288898. Thanks for the discussion helping me understand what this is (and isnt!)

  • lloram239@feddit.de
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    Ultimately this is a problem that’s never going away until we replace URLs. The HTTP approach to find documents by URL, i.e. server/path, is fundamentally brittle. Doesn’t matter how careful you are, doesn’t matter how much best practice you follow, that URL is going to be dead in a few years. The problem is made worse by DNS, which in turn makes URLs expensive and expire.

    There are approaches like IPFS, which uses content-based addressing (i.e. fancy file hashes), but that’s note enough either, as it provide no good way to update a resource.

    The best™ solution would be some kind of global blockchain thing that keeps record of what people publish, giving each document a unique id, hash, and some way to update that resource in a non-destructive way (i.e. the version history is preserved). Hosting itself would still need to be done by other parties, but a global log file that lists out all the stuff humans have published would make it much easier and reliable to mirror it.

    The end result should be “Internet as globally distributed immutable data structure”.

    Bit frustrating that this whole problem isn’t getting the attention it deserves.

    • Fama@kbin.social
      link
      fedilink
      arrow-up
      3
      ·
      1 year ago

      No offense, but that solution sounds like a pipedream that wouldn’t work on a technical level. So you wish to keep not just the item someone published, but previous versions of it, have mirrors of it and tie it up in some sort of a blockchain thing. That sounds insanely more resource heavy than just hosting the document itself on one instance somewhere. It would be much more reliable sure, but currently even companies like reddit can struggle with all of the traffic, similarly with smaller open source projects like Lemmy instances or kbin, and your solution is to increase the amount of data?

      • lloram239@feddit.de
        link
        fedilink
        arrow-up
        0
        ·
        1 year ago

        That sounds insanely more resource heavy than just hosting the document itself on one instance somewhere.

        It really isn’t. Most content out there is already immutable, you don’t see people uploading the same Youtube video five times with minor changes or editing their images after the upload, most services don’t even allow that for users, at best you can delete and upload a new video.

        Furthermore, the blockchain would only contain metadata, not the actual data, so it’s automatically thousands of times easier to store than the data itself.

        Mirroring that content is a complete separate and optional part of the problem, the important part is having content named in such a way that I can go to a mirror and ask “do you have XYZ” and get an answer that you can trust. With URLs that’s impossible, as they can show different content whenever they want.

        Also this isn’t exactly a new idea, that’s how most software development already works these days. A Git repository stores a copy of every little change, and every download retrieves that complete history. What’s missing is some infrastructure on top of that that links all the different repositories together into one namespace (GitHub kind of does that internally, but that’s of no help for repositories hosted elsewhere).

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

          Ok, so what if this blockchain has a metadata link to a video, which is hosted somewhere, and i remove that video from that host? How is that different than just a URL pointing to that video if the blockchain just holds metadata?

          I don’t understand what you are solving.

    • Otome-chan@kbin.social
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      zeronet solved this problem years ago and no one cared lol. how it works is it uses public/private key addressing for addresses, and then uses p2p torrent style filesharing for hosting. it lets the owner of the private key update their content while also having the sites be hosted in a decentralized manner. since the public keys are immutable, the addressing never changes.

      it also has a federated system for it’s social media where the frontend/gui for a site is separate from the data storage, and it aggregates the collective data sites that you have downloaded/fetched.

      It has it’s problems but it works remarkably well. but unfortunately it’s dead since the dev vanished and people lost interest.