My kbin instance's data (text data, that is) probably takes up less than 8 GB right now, and I've had it running about two weeks. Media storage (which I do through S3) is around 5 GB so far. Kbin does do media mirroring different than Lemmy though (I think), so YMMV. I think Lemmy mostly links to the original instance's media object as the source.

The main thing I found eating storage on my server was a lot of old Docker images (and volumes) from me trying to get everything up and running. If you are using Docker you could try doing a docker system prune --all to get rid of unused images/build caches (anything that isn't running currently).

At least you got yourself into the contributing mindset. Tackle the next issue!

Don't they know not to use the window-git AUR package? It's a development build and could be unstable/unsafe.

Yo, thanks for creating a new community! Can you share the name and instance for your community, like '[email protected]' (or whatever it may be called). That way folks can get to it on their home instance and subscribe.

Thanks!

EDIT: I see that the link of the post leads to the community, d'oh. I think we should include the community name and instance in the text of the post also.

I think that would be worth it, yeah. Of course if you are hosting it on your home network there will be some added security concerns (and that might make it better to only allow signups to friends/friends of friends/etc). The way I see it is that some instances are going to host the largest communities, and therefore those instances are going to need to handle all of the incoming/outgoing updates to posts in those communities. Right now they can't do that reliably and push updates out to all of their users' devices.

So in the long run I think having small/medium instances (say a couple hundred, not tens of thousands of users) will be the way to grow. These smaller communities can push updates to their smaller user count reliably, and then have more resources to handle federated content coming in and going out. I think scaling for the incoming/outgoing federation requests would be easier than for direct user activity. Federation stuff can be queued and then spread over time, but user requests cannot be.

You are totally right and my brain definitely farted on that one. Extreme is extreme to me I guess. I'll edit to reflect that.

Good point. Nothing against the larger instance owners of course. If my little instance got super popular somehow (like being recommended in guides on how to join lemmy/kbin), and thousands of users got in per day, I could see issues happening just like this. I don't know the ins and outs of tuning this software for performance at scale, and I know I couldn't learn it fast enough if my instance faced very fast growth like lemmy.world has.

I think admins are going to need to turn registrations off periodically, as they scale their hardware (and their knowledge) to run it for more users effectively.

This is the problem we are having with fast growth on a few select communities. The largest servers are being bogged down simply because the software has not been tuned for these large types of instances yet. ActivityPub works best (in it's current state) by spreading users over smaller/medium sized instances. Folks need to take a look at other instances (and I agree it is hard to find them for a newcomer). You can look at https://fedidb.org/ to look at instances that have been indexed running kbin, lemmy, and other software.

Joining a smaller instance means that your server is not being bogged down by tens of thousands of other users trying to pull updates to their devices at the same time. You can still see the content from other instances, and in many cases it is more reliable because your smaller instance actually has the resources to handle pulling in the posts you want to see. The server-to-server communications that make content federation possible are less resource intensive than pushing updates to user devices. Less users on an instance = more server resources to actually federate content. In the future I am sure instances like lemmy.world will be able to handle the user traffic and federation traffic smoothly, but for now the best way to ensure stability is to join a smaller instance.

(Plug for my instance: https://remy.city, a general purpose Kbin instance. I set it up for personal use but anyone is free to join me in using it. I have defederated from the instances with more extreme viewpoints userbase-wide (like lemmygrad and exploding-heads), and from lemmynsfw.com because of content hosting concerns. I'm open to suggestions on others.)

Bummer. Yeah, I think kbin.social hasn't gotten those changes added in yet. I've just been pulling the new updates once/twice a day onto my instance. It has broken things a couple times though so I get why the larger instances are waiting for actual 'releases' of kbin.

In your browser, if you go into the menu there should be something like 'Install', 'Add to Homescreen', something like that.

On chrome it is add to homescreen, but there is also a pop-up at the bottom that gives an install button. The browser menu should be the easiest spot though.

It creates a shortcut on your homescreen and allows the site to run in full screen mode, so it acts like a native app.

Looks like that's been fixed actually (if your instance is up to date enough, that was merged in 5 hours ago). I had to reinstall the PWA for it to take effect.

That might be android only, I'm not sure. I remember seeing a pull request about it having to do with something in the PWA manifest.

That'll be slick!

Thanks for the great work on this @ernest, and every contributor who's dove in and made a PR.

There is also Kbin (that I use) which can communicate with Lemmy. Since they both share the "sections/communities/groups with threads in them" concept, they can interact pretty well.

I've seen folks calling it the "Threadiverse" because of the different software that servers run.

Federation is the process that pulls content in from other servers (e.g. lemmy.world, beehaw.org, fedia.io, mastodon.social, etc.) All of these different servers can communicate and share content with each other.

If you turn federation off, you only see content from your "home" server, which in your case is kbin.social (in mine it's remy.city).

Well said, thanks for this info! I was in the camp of thinking "of course the money goes to Wikipedia's upkeep" but I never examined it closely enough.

There are ways to write links in such a way that they should keep you on your instance, but I'm not too familiar with them. I wonder if it would be possible to "precheck" links that load on a page, and if any point to content that can be federated, kick off the process of pulling that content in. Then when the user clicks that link, it would take them to the content on their home instance, where they can interact. That way users wouldn't need to deal with formatting links a certain way, it would just happen automatically (if your home instance software supports it).

That's the one--thanks!

The thing about federation is that every server basically copies any content that the users on it want to see. So if a comment/post is made on lemmy.world, lemmy.world sends out an update to every other server on which a user is subscribed to the thread/community/user. So each instance that has a subscribed user ends up having to process the new comment/post. If a Meta community came in with say, a million users, now every instance has to process the comments for all those users (that is, if folks on those instances want to see that Meta content).

It is a bit inefficient, but it's just the way a decentralized network has to function. I could see many people thinking that any time you open a thread, the data comes in from the originating instance, i.e. that your home instance doesn't store the data you are viewing. It is unfortunately, and I think it will be a problem in the future as communities grow.