Yes, that and the main kbin.social instance turning off federation for a while. Between that and the way keeping kbin.social up and running seems prioritized above making running instances easier, I dunno. I just don’t get the right vibes. Similarly, when people join kbin, they’re just encouraged to go to kbin.social. Unlike Mastodon or Lemmy, I haven’t really scene the developers recommending or even listing other instances. And as someone who doesn’t use PHP for much of anything anymore (and doesn’t want to), no, none of this is straightforward. Compare it to Lemmy, where deploying your own instance is just editing a couple files and running a single script away. Of course then you get to spend five days realizing the default nginx configuration isn’t useful for anything more than a single-user instance, and the postgresql config really needs tweaking, and so-on and so-on. But at least one-click Lemmy installs, helping to keep the fedevirse distributed, are within reach. It doesn’t feel that way at all for kbin. And I don’t want Kbin (or anyone else) to have control of the fediverse on one or two large instances. Also, RabbitMQ also has a todo section. I’ve been hosting things online for something like 15 years, but I have no idea what RabbitMQ even is, never mind how to set it up, or what the implications of running it might be, or how I might monitor it, or what could happen when it crashes. Rust, nginx, and postgresql all feel like well-understood, popular, and well-supported technology. If something goes wrong with them, I have pretty much endless support via Google, or if worst comes to worst, it would be easy to find a contractor to hire. The technology kbin is using feels, at least to me, much less known and understood. OK, Lemmy does use pict-rs, and I’m not aware of anything else that does, but pict-rs feels simple enough that it probably doesn’t matter, and it probably won’t fall over in ways that I would need help fixing.