/kbin server update - or how the server didn't blow up
/kbin server update - or how the server didn't blow up
Currently, on the main instance, people have created 40191 accounts (+214 marked as deleted). I don't know how many are active because I don't monitor it, but once again, I greet all of you here :) In recent days, the traffic on the website has been overwhelming. It's definitely too much for the basic docker-compose setup, primarily designed for development use. I was aware of the possible consequences of the situation happening on Reddit, but I assumed that most people would migrate to one of the Lemmy instances, which already has an established position. I hoped that a few stray enthusiasts would find their way to kbin ;)
The first step was to upscale the VPS to a higher version (66.91EUR). It quickly turned out that it wasn't enough. I had to enable CF protection just to keep the website responsive, but the response times were still very slow. At this stage, the instance was practically unusable. The next step was a full migration to a dedicated server (100EUR, the current hardware). It can be done relatively quickly, so it resulted in a 5-minute technical break. Despite the much higher parameters, it didn't get any better. It became clear that the problem didn't lie there. I'm really frustrated when it comes to server administration. That was the moment when I started looking for help. Or rather, it found me.
A couple days ago I wrote about how kbin qualified for the Fast Forward program. To be honest, I did it out of pure curiosity and completely forgot because a lot was happening during that time. During the biggest fire incident, Hannah ( @haubles ) reached out with a proposal to help. I outlined the situation (in short: the server is dying, I don't even know what I need, help! ;). She quickly connected us with Vlad ( @vvuksan ) and Renaud ( @renchap ). I was probably too tired because I don't know if the whole operation lasted 60 minutes or 6 hours, but after a series of precise questions and getting an understanding of the situation, the guys themselves adjusted the entire job. I love working with experts, and it's not often that you come across individuals so well-versed in the fediverse. Thanks to Hannah's kindness, we will be staying there a bit longer. Currently, fastly.com handles the caching layer and processes images. Hence those cool moving thumbnails ;)
Things were going well at that point. I could disable Cloudflare protection. Probably thanks to that, many of you are here today, and we got to know each other a bit better :) However, even then, when I tried to enable federation, the server would stop working.
Around the same time, Piotr ( @piotrsikora ), whom I already knew from the Polish fediverse, contacted me. He is the administrator of the Polish Mastodon instance pol.social, operates within the ftdl.pl foundation, and specializes in administering applications with a very similar tech stack. I made the decision to grant him server access. It only took him a few moments, and he came back to me with a few tips that allowed us to enable federation. In the following days, there was more of it, and we managed to reach the current level. I think it's not too bad.
Nevertheless, managing the instance has taken up about 60% or more of my time so far, which prevents me from fully focusing on current tasks. That's why I would like to collaborate with Piotr and hand over full care of the server to him. Piotr will also take care of the security side. Now I have to take this much more seriously. We still need to work out the terms of cooperation, but I want you to know the direction I intend to pursue.
We also need to migrate to a new environment because one server will sooner or later become insufficient. This time, I want to be prepared for it. This may be associated with transient issues with the website in the coming days.
The next two updates will still be about project funding (I still can't believe what happened) and moderation. The following ones will be more technical, with descriptions of changes and what contributors are doing on Codeberg. I would like to be here more often, but not as an admin, just as myself.
Thank you all for this.
P.S. In private messages, I also received numerous offers of help that I didn't even have a chance to read and respond to. You are the best!
You're viewing part of a thread.
The Fediverse needs to get a handle on advertising and revenue, and what's considered acceptable and not acceptable. It's easier to do this now than after a bunch of bad actors have shown up and ruined things. My initial idea: a standard API that provides the contract between the service and its users. It would include things such as how, where and when advertising is used in that instance, whether you can opt-out, and how to do so, operating costs, revenue sources and relative amounts, etc. This API could be leveraged to aggregate lists of instances that end users could then sort and filter to find those that meet with their individual values. It could also become part of the standard UI so that users could easily locate where to support the operator of various instances, instead of relying on posting messages and hoping somebody knows where to donate (and that they are providing the true information).
Yes, I do realize there's a bit of a "herding cats" aspect to this. And there are those who are just completely opposed to any sort of "monetization" at all, but to me that's just an argument in favour of making it as transparent and discoverable as possible.
This is a slippery slope. Reddit used to be open-source...
First, just because reddit fucked it up doesn't mean that's the only path forward.
Second, if the Fediverse community doesn't address advertising, somebody will. Probably somebody with deep pockets, and it won't be in the way anyone other than the advertisers wants it. Sure you can defederate them, but that's most likely going to result in a fragmented Fediverse with 95% of the users in a corporate walled-garden and 5% of users in a free (however you want to define "free) but content-poor open world.
I'm not suggesting that advertising should be pushed between instances. Quite the opposite: advertising (if allowed) would be up to the individual instance to decide if, when and how users of that instance (i.e. those that are browsing that instance using that instance's UI/application/website) would see advertising. Don't like ads? Sign up with a different instance. The API I've suggested is not for publishing ads. It's purely informational to enforce transparency about how/where the funds to run an instance come from, and, if you so desire, tell you the official way to directly provide financial support. That information could also be used when subscribing across instances, to warn of potential bias, or about their advertising policies if you decide to visit directly. I'm basically suggesting a way to encode the suggestions in https://www.eff.org/deeplinks/2022/11/fediverse-could-be-awesome-if-we-dont-screw-it, point #6 in a machine-readable way.
First, just because reddit fucked it up doesn't mean that's the only path forward.
Hundreds of thousands of people on Fedi are yet to be convinced to this. Your opinion is unpopular, and any try do combine fedi with funding by advertisements could likely break the fediverse rather than make it more sustainable.
Upvoted your comments inter alia for courage.
Hundreds of thousands of people on Fedi are yet to be convinced to this. Your opinion is unpopular, and any try do combine fedi with funding by advertisements could likely break the fediverse rather than make it more sustainable.
I'm not sure what "opinion" you are referring to. I'm not advocating that I want advertising or commercial entities running the majority of the Fediverse instances. Or is it my suggestion that it's possible to avoid that fate, even while suggesting that it's inevitable that advertising will eventually arrive?
Really my main point was we need to have some way of ensuring that instances are able to pay their operating costs. At least until unicorn farts and rainbows are accepted in exchange for hosting, bandwidth and technical services.