[-] hawkwind@lemmy.management 2 points 1 year ago

You mean blocked instances right? AFAIK an instances “blocked users” is not published in aggregate. You’d have to comb through the modlog.

[-] hawkwind@lemmy.management 2 points 1 year ago

More “portable” and secure identities would have been a good feature. The client could have handled most of the crypto required for signing and validating content. As it stands now, the instance Admin has complete control over your identity. Portable communities would follow that easily.

Most of the syncing issues are actually between the large instances or instances that having performance issues.

[-] hawkwind@lemmy.management 2 points 1 year ago

When Palo Alto sells your dipshit CIO one firewall appliance per virtual server. “Somehow. Someway,” says the salesperson, “we’re gonna get even more firewalls in here!”

[-] hawkwind@lemmy.management 2 points 1 year ago

If the only criteria to be in a private channel for admins is being an admin, there’s no use making it private. ;) Unless your just looking to filter out bad actors who don’t want to take 5 min and 5$ to make an instance.

[-] hawkwind@lemmy.management 2 points 1 year ago* (last edited 1 year ago)

So if I’m understanding this right, the bot account you create for this is the one subscribing to every community, so it’s known to the local system, right?

Yes

As long as I’m not mixing up my main account and my bot account, there should be no observable change on my own account?

Correct, I have it functioning this way and it works great.

How is storage affected on this? If the bot account is subscribing to a number of communities across the fediverse, all that remote content is going to take up quite a bit of space, no?

It does and it will continue to grow. This not not something the tool takes care of, not cleaning up anything old or stale. Space management and "unfollow" is on the roadmap! Currently I can only speak for myself and it is EVERYTHING and it is about 0.25 GB / day of database, and 6-10 GB / day of images.

And will 2FA be supported at any point?

Not on the roadmap. I don't know how api calls in general work with 2fa since I have not tested or enabled it on my instance. :( Sorry.

EDIT: Changed database/pictures ratio after double checking actual numbers and not looking at used filesystem. :(

[-] hawkwind@lemmy.management 2 points 1 year ago

It can be on instances with lots of users and open signups.

[-] hawkwind@lemmy.management 2 points 1 year ago

You should write something that detects indiscriminate subscribing and automatically defederates with them.

[-] hawkwind@lemmy.management 2 points 1 year ago

It's a combination of software and scalability issues. There's no ONE thing the lemmy developers can code that will magically fix it, and there's not ONE thing the admins can do to make the current code run on the currently deployed infrastructure. The software was not tested to work at the volume and scale we're seeing between the top 5 instances, and not all of the admins are prepared to work through it. It requires a lot of "togetherness" to change and test the code with "right-sized" resource and operations management. Pretty mature stuff for a rag-tag group of reddit refugees. :)

Right now, lemmy.world's admin team is probably doing the best job of collaboration and communication (props to everyone else too.) Prioritizing the issues and focusing on them for the sale of the actual users is the key. Some admins are just expecting the next upgrade to fix everything without being involved. Blaming the software is not the solution. Eventually that might be a good position, but this early in the game it just won't work. Everyone is still working hard!

Lemmy was written an tested at what is essentially: "raspberry-pi scale" and has been forced to make the maturity jump to "could-scale," practically overnight. It sucks the growth isn't smooth, but it is totally understandable.

tl;dr There is no github issue because there isn't one problem in code that can fix it.

[-] hawkwind@lemmy.management 2 points 1 year ago

aaaaaand we’re done.

[-] hawkwind@lemmy.management 2 points 1 year ago* (last edited 1 year ago)

Correct. All also includes communities fetched but not subscribed to, however these are more like stubs. They are in your database but not being updated with activity since no one is subscribed. At least that’s my understanding.

[-] hawkwind@lemmy.management 2 points 1 year ago

I think you're right. People will gravitate to the most stable large instances because their "All" will be as close to 100% as possible without doing anything special. I wrote a script to seed instances and update subscriptions, but it uses a single account that is subscribed to everything so that other users can see everything. That's not something that would normally happen. Maybe that needs to be part of the base software?

[-] hawkwind@lemmy.management 2 points 1 year ago

That is exactly what that means and it's frustrating to say the least, because it's not clear that's what's happening.

view more: ‹ prev next ›

hawkwind

joined 1 year ago