That, is actually kind of fascinating and may be important info for someone doing a follow-up investigation. If that was the bad actor phishing for moderation access, why would they need that, when they already had an admin account? If it was legit, then it's super sus. whoever this app developer was needs to have a little light shone on them.
hawkwind
TBF, at least you're doing something.
You do you. I would tell my users I have no idea what's going on, and definitely not say "using your open tabs is probably fine."
I think this carrying on without providing more information is reckless. Does an actual admin from this instance really know what happened or are you just taking a bunch of random commentary and speculation as gospel then telling the users "we're good."
I don't know if you're trying to be funny or not but that is pretty funny. Those poor reporters thinking "how convenient! they obviously know what is wrong because it's right here in the list!" But it's there to make it easy to sort into the trash.
People can defederate from an instance for any reason they want, but if I get what you're trying to say: you think people should defederate from any instance that has a user that subscribes to all of their communities.
I actually wrote it with the flip side of your centralization argument in mind. If a community exists outside of the popular ones a user may never even know of its existence. Having more show up SHOULD be better to prevent centralization no? It requires the users to change their browsing behaviour but at least they don’t have gonsearching offsite.
Yup. 256 GB should be enough database space for anyone though.
A handy chart: https://i.pinimg.com/originals/18/a4/2f/18a42ffa5c733c7c6bb86b547fb0647f.png
It's a cruel irony that we use an enclosure to help print materials with a higher Tg but the printer itself is printed of materials with the same or lower Tg. It makes perfect sense that your ABS parts are going to get mushy when you crank your heated bed to 100 and put the whole thing in a box. :)
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.
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!
I've been pondering trying to make one, but it's not going to be a cake-walk. The tool (that was a script) I wrote ruffled some feathers for it's potential to destroy the lemmyverse. While I don't believe that could happen. I'm still interested in something easier and more integrated.
The theory is simple and I am willing to take a stab at it, but there might be road blocks trying to make or incorporate changes to the actual lemmy code.