It legit kinda sucks that, right after I move on here, some drama happens, and now I can't talk to some of my friends because an admin decided that their server and community shouldn't talk with this one.

I'd normally just sigh and shrug it off, but some of my friends on the other side are people who built part of the existing network and its protocols.
@deadsuperhero i mean you could just switch back
@ariadne Yeah, I might. The drama isn't worth it.

Fucking phenomenal UI, though.
@deadsuperhero i would have used a misskey fork if i could have figured out how to scale it horizontally
@ariadne @[email protected] Horizontal scaling with Firefish is pretty easy, just set up worker processes on other servers with workerOnlyMode in the config file
@kainoa @deadsuperhero there is so much more to horizontal scalability than that. does firefish support sharding database accesses so that reads go to secondaries and writes go to a primary? can i run multiple http frontends without them fighting over state?
@ariadne @[email protected] first is yes if you use a tool like pgbouncer to set that up, second is no but we're working on it. I 100% agree that there's much much more to horizontal scaling than more workers, but it's not a bad start. Misskey doesn't have anything remotely like that even.
@ariadne @[email protected] for DB stuff specifically, we're gonna start moving away from Postgres for most data and towards (optionally supporting) ScyllaDB, which is inherently more scalable out of the box.
@kainoa @deadsuperhero why do you say that Scylla is more scalable? in some cases, with some access strategies, it can be, but it’s not automatic. that’s like saying that bigquery is more scalable than postgres. it depends on the job, how the access patterns are, etc.
@ariadne @[email protected] fair enough (also talking more generalized because it's 1 am and I'm eepy), but I'll put it like this -- the way we're planning on approaching things, it'll be more scalable. The Postgres code inherited from Misskey is....less than ideal to say the very least. This'll give us an opportunity to properly implement sharding, snowflakes, etc. As for the frontend issue, I agree it's very important, hence why it's actively being worked on (I was doing some of that work earlier tonight!)
@kainoa @deadsuperhero pgbouncer is not the most reliable of softwares, i would suggest supporting sharding natively: it fits very well into the kubernetes model if it natively supports sharding. the frontend issue is also important