v.0.0.6

v0.0.4 - Per requests and concerns: Defaults changed and options added to prevent overloading servers, hitting rate-limiting, filtering to top x communities, etc!

Thanks for your support!

  • hawkwind@lemmy.managementOP
    link
    fedilink
    English
    arrow-up
    4
    arrow-down
    4
    ·
    1 year ago

    It increases load during execution. Afterward it’s not significant. My instance is heavily instrumented and monitored. The load this incurs subscribing to 24000 communities is less than adding a single, moderately active user to your instance.

    It’s a huge miss if the intended design was to silo information.

    What this provides, as far as I’m concerned, is essential to prevent centralization to a few instances.

    Is there a better way to do it inherently in Lemmy itself? Probably, and I am excited to help with that!

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

      It is a significant difference if an instance has to federate literally every post made on the lemmyverse.

    • floofloof@lemmy.ca
      link
      fedilink
      English
      arrow-up
      3
      arrow-down
      1
      ·
      1 year ago

      Well that sounds quite reasonable then. It definitely answers a need for better discoverability of material on Lemmy. And it would be great if something like this could ultimately be integrated into Lemmy itself.

      • hawkwind@lemmy.managementOP
        link
        fedilink
        English
        arrow-up
        1
        arrow-down
        1
        ·
        1 year ago

        I think your idea is on the right track when thinking longer term and assuming the worst case in both design and admin behavior. :)

        The whole network needs to be split into “active” and “archive.” New activity (or at the very least stubs to where new activity is happening) needs to be updated regardless of where it occurs without having to capture anything extra.