• RandomBit@lemmy.sdf.org
    link
    fedilink
    arrow-up
    23
    ·
    1 year ago

    Yes, with a major caveat. An instance will search only communities that at least one user on the instance is subscribed to and only as far back as the time the first user on the instance subscribed to the community.

    • sarsaparilyptus@lemmy.fmhy.ml
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      Lemmynet’s design structure has some weird choices in it, motivated either by laziness or to keep garage servers from being overwhelmed, and that’s the biggest and weirdest one. I’d like to see federation = full and complete synchonization from server launch to present, but I doubt the motivation is there to implement it. Maybe things will be different when kbin eventually surpasses Lemmy

      • Mereo@lemmy.ca
        link
        fedilink
        English
        arrow-up
        2
        ·
        1 year ago

        Interesting, can you explain a little more? I’m very curious.

      • Amju Wolf@pawb.social
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        1 year ago

        If that was mandatory you’d kill of smaller/personal servers, which is bad.

        Should be a host option to decide what to sync.

        Oh and you’d also need to solve an issue with a new instance joining and completely flooding everyone else with requests for past content.

        It’s all solvable but the reasons to do it this way aren’t just random.

        Oh and you also face issue with duplicate content (between instances) which search engines generally don’t like.

        Ideally there would be native integration for search engines where they’d just connect with the fediverse like another instance and have special handling for the content. They could either display the content in their own UI or allow the user to pick their default instance that’d open the given content

        I suspect that’d be the best way but we won’t see it unless federated apps become mainstream.