Issues like the one that occurred are typically resolved within an hour, hence this post - mainly to quickly inform that work is underway on it. But you're right, I'll strive to improve communication in the future. Your examples gave me something to think about, thanks.
I don't quite understand what you mean. The problem is that in such a case, it's challenging to provide a specific estimate. That's why I occasionally provide updates in case the work is prolonged. It seems to me that this is how it works. Issues arose without any interference in the code or infrastructure. I addressed hardware problems, but it turned out that wasn't the only issue. Throughout this entire period, I've been attempting to ensure that the instance operates as smoothly as possible. It should be significantly better now, but I'm still actively working on it. Unfortunately, taking a holiday break here doesn't help either.
Yeah, It's true. Since Sunday, I've been noting errors that I'm still working on resolving. It doesn't make it easier that it's the post-holiday period, and due to travels and security measures, it's not the easiest task. I'm working to get everything back to normal as soon as possible.
Arghhh... Sorry, I replied with a longer message from my phone at that time - at least that's how it seemed to me. Now I've noticed that the response didn't send. In short, there must be an application account on the specific instance due to limits, but catch me on Matrix - we'll discuss it in detail.
Ah, there's one more thing I forgot. I would like adding a new post/thread to be done asynchronously to reduce client-side time, but this might extend to next week because even though I have the foundation prepared, I want to thoroughly test it.
This little guy. I won't take a current photo because even though it's quite snowy in Poland, he won't avoid any puddle or mud, so he temporarily changed color :p
By default, it's 11MB if I remember correctly. However, during the recent issues with the instance, we could modify this value at the server level. Once Piotr is back, I'll verify and restore the default values.
I feel that our visions for the project's development are too different for this to succeed. At this stage, it will definitely be better to work on our own things, /kbin is open source, so there is no issue with that. There are several reasons for this link, link
Additionally, the suspension of other work was a conscious decision on my part. I believe that the code at this stage needs to be deeply refactored, and that's exactly what I am doing. Solid foundations are the only option for the project to survive and grow in the long term, and to be properly scalable. Adding more blocks to what I have always considered a prototype (which forks do) makes no sense to me.
Hey, I will get back to this thread and the comments at the beginning of next week. I am able to quickly address some of the issues you mentioned in your post. Changes will undoubtedly be implemented gradually, but for now, the redesign of the ActivityPub module takes higher priority. Once that is completed, the development of the frontend part of the platfrom will truly pick up pace.
There are some tools there that I use for the development of the AP module. Among them is Yunohost, which allows for quickly creating test instances of many federated applications with just a few mouse clicks. It's a good choice for someone looking to embark on a self-hosting adventure.
My priority is definitely the development of kbin-core, especially now that work on the app has started. For now, I prefer to focus my attention on adapting the API to the latest features. It may turn out to be necessary sooner than expected ;)