kbin.run meta

I've added a handy blocklist of instances that have become a vector of fediverse spammers to the banned instance list, you may review them here (bottom of page): https://kbin.run/federation

Spam blocklist in question: https://github.com/Mastodon-DE/blocklists

I'll continue to remove spam threads and posts as time allows.

Hi everyone, I saw a conversation on a certain magazine about the wording of kbin.run's terms of service. I'm not going to reply there because its unproductive and irrelevant to the conversation being discussed. I do; however, encourage everyone to (re)review the privacy policy and terms of service of the instance.

A reminder that this is a US based instance and I will enforce compliance with all established US laws and comply with all law enforcement requests, subpoenas, etc. I am not a lawyer and I'm not going to pay a lawyer to write an all encompassing fediverse friendly TOS, although if that's something people want, please donate to the site so I can afford to hire one. I'd like to think this is one of the most transparency friendly instances out there between all the information I provide in the about, FAQ, privacy policy, terms of service, etc.

With regards to the specific concern about the "third party" wording in Section 11. of the terms of service... outside of the realization that any federated instance subscribed to any user or magazine on this site is by definition a third party... there are also automated measures in place to log and report users that post or share material flagged as child sexual abuse material (CSAM) detected with hashes provided by the NCMEC. This is a ZERO tolerance area and I have already reported several instances that either don't care about this or have no moderation in place to handle it.

Thank you for your understanding and I welcome a healthy discussion if desired; otherwise, please submit a user account delete request and I will remove your account from the site.

When I open kbin.run in the browser it tries to download a file "master.m3u8"

#meta

Sorry about the site's instability as of late... for those unaware, I self-host kbin.run behind OpenMPTCProuter to aggregate 3 separate Internet connections together and route the resulting Internet traffic via a VPS endpoint in SBA Edge's Chicago, IL data center.

The latest snapshot of OpenMPTCProuter is using a buggy Linux kernel that I've since manually upgraded to a more recent version (6.5 vs 6.1) in an attempt to solve the networking lockup problem that's been causing the site's routing to stop unexpectedly. I'll continue to monitor the connection health and debug further if necessary, but I'm hopeful this manual patch mitigates the issue until the next major kernel release gets pushed to the project.

I have blocked lemmy.ml but posts in its various communities still show up in my commented feed.

Do I have to block every community?

Another set of notes have been published, by @[email protected] on the same Meta/Threads meeting in December that I also went to:

http://plasticbag.org/archives/2024/01/how-threads-will-integrate-with-the-fediverse/

I think it's consistent with what I wrote: https://reb00ted.org/tech/20231208-meta-threads-data-dialogue/

#meta #threads

I was live testing a fix for a different 500 issue and I might have accidentally caused 500s to be generated elsewhere... should be stable now. If the site is acting stupid, there's a 99% chance it's because I'm either live testing a code change or messing with something else in the background.

Sorry for any interruptions and happy holidays!

On kbin.run/sub as well as kbin.run/sub/newest, I see a post (specifically this one) from @[email protected]. I double checked and I am not subscribed to @[email protected].

Out there in the broader Fediverse there is a big debate on whether to block federation with Threads when it launches or not.

I for one have more of a "wait and see" attitude but I'd like to know where the admins stand, and if any action has already or is set to be taken

I have kbin.run loaded with a feature branch that enables post reports being sent to moderators of remote instances: https://github.com/MbinOrg/mbin/pull/249. There are a few technical issues that need to be worked out, but the basic functionality seems to be working.

Also, for those unaware, you should see that Mbin now enumerates all remote moderators for each remote magazine (scroll down to the "Moderators" panel on the right-hand side of the magazine); something we added in https://github.com/MbinOrg/mbin/releases/tag/v1.2.0. Instance to instance DMs do NOT work in Mbin (or kbin for that matter), but that is also in the pipeline to get implemented.

A big thank you to @[email protected] for getting these critical moderator features integrated into Mbin.

Sorry for any site interruptions/instability last night into this morning (CST), but I ran into a bit of a problem with a recent Mbin update that was causing excessively high CPU usage with the message workers that is looking more and more like an upgrade that went rogue... or it's the only explanation I have since everything is running fine after downgrading and performing the upgrade again.

However, I've since moved kbin.run to my primary self-hosted Proxmox host. The VM specs are listed on the FAQ page, but the bare metal host has a total of 128 GB of OC-ed DDR4 and a Samsung 980 Pro 2TB NVMe (with updated firmware)... plenty of room for activities now. This was a move I had planned to do in a few months, but figured I might as well do it now to exercise my backups and disaster recovery plan.

I also re-optimized PHP and Postgres for the new environment, so hopefully things are running as fast as possible with this VM configuration.

Enjoy!

But what happened to part 1 and 2? I guess we'll never know.

I spent a fair amount of time this weekend optimizing the interaction between NGINX, PHP, Symfony framework tuning handles, Postgres and Cloudflare before I give up on this server and move kbin.run to a more powerful machine. The big change that will improve performance: I'm force rewriting the caching headers on images that are being incorrectly served by Mbin (and /kbin) using Cloudflare page transforms and caching rules... but the underlying problem is something the Mbin team is aware of and will investigate further.

I hope everyone enjoys the boost in page responsiveness now.

Have a nice week!

At least 1 user needs to be subscribed to a magazine in order for it to receive federated updates, so keep that in mind after searching for a new magazine/community. I get subscribed to everything by default (~~hopefully Mbin will change this behavior in the future~~), so if it's not a magazine I want to see in my feed I will unsubscribe. :-)

EDIT: i've pushed a code change to Mbin so that the admin user is no longer auto-subscribed to new federated magazine searches. https://github.com/MbinOrg/mbin/pull/237

I've offloaded the image processing to a separate process/server and I've been wondering, has anyone noticed any improvement in image loading over the past few days? I don't like overcomplicating the site's configuration, but I was hoping this change boosts the performance at least a little.

Also, for those interested, I've added several donation methods to the site under the FAQ page. 100% of the proceeds are allocated to the operation, maintenance, and expansion of kbin.run. My only goal is to provide you with the best performing kbin/Mbin instance available and I hope my transparency about the site's expenses reflect that.

I’m on mobile right now. I tested and this does not happen on other kbin instances. It also seems to happen with some magazines but not others and I’m not sure why—best guess is some of the magazines are totally new to this instance and some are not.

Hi all, so it has been a couple weeks since the initial launch of kbin.run and I'm curious to hear what people's opinions are and how they like the overall experience here vs. other kbin instances. Generally speaking, I think kbin's stability has greatly improved since launch as the first turn on was a very haphazard attempt at getting an instance going using very limited documentation to configure all the interconnected services. There are still a couple of hacks in place to keep federation working smoothly, but I do anticipate official code changes in the near future will greatly improve the overall kbin experience.

I honestly don't know how many people actively utilize kbin.run, but I do see we have 56 registered users (2 pending deletion) as of posting this thread. The primary server that runs the site is hardly breaking a sweat, so tell your friends to join us if they're looking for a lightly loaded instance.

Also, if you're searching for a community that seems to be missing in the fediverse, feel free to create a magazine to support it here. I made a few that I'm interested to see gain some momentum, but there's nothing stopping anyone else from doing the same.

Thanks as always and enjoy!

EDIT: I've added the monthly cost breakdown for kbin.run to the FAQ page.