I appreciate your frank honesty and response but do want to make ABSOLUTELY sure everyone reading knows:
PluralSpace is fantastic. I’ve personally spoken to the developer and we exchanged initial schemas for data exchange and all that early on. Both of us have changed the code so much that we’ll need to sync back up, but I understand Drexel (the dev) went through a lot in his personal life and is still catching up.
I have every intention of supporting their platform. I had every intention with Florality too but their PR Lead Jamie called me a N*zi moments before I hit send on the stuff to let people import back IN to Florality and realized the universe was sending me a message LOL
That’s why Florality only imports and not exports.
Ourcana’s Online features were slightly delayed after the PluralKit API ban that went sideways last week. I lowkey had a little mental spiral and said “well I’ll fix that alongside shipping Online” and only managed to get the fix out to web…
By the way any loser with a single laptop can DoS (not even DDoS) PluralKit just by hitting the oembed.json and systems settings endpoints with random noise. You can mutate the data of other systems with one weird CLI command, and the rate limit protecting the mass spidering of user IDs isn’t just nonfunctional — you can abuse it to lock OTHER people out lmao from sheer traffic volume!
These are “not real issues” as I’m an “unreliable source of information” if you ask Iris (PluralKit hardware owner). I’ve done everything short of filing a CVE because that’s work, or patching the code because they aren’t gonna accept my contributions regardless lol
And the PluralKit downtime? They don’t model back pressure at all, and modeled ingest pressure wrong. This is coder speak for “no idea what I’m doing at scale”. When the bot starts struggling under traffic, a mix of three bugs in code compound to cause reboot loops that reboot back into a state where they let themselves get flooded with traffic again. One bug ingests too many events, another bug crashes as there’s a max limit to events that can be ingested in a moment, and the third bug throws out the error log that explains this because of a method called IsOurProblem that returns false and not true here
- misunderstanding of Rust asynchronous model that just happens to work most of the time but gets worse under CPU load
- ingest queue is a 10k list and not an unbounded vector with no limit (we’re talking megabytes of RAM here they’re “saving”)
I fixed all of these in an evening. I pushed the code up to my GitHub. I told them the issues. They looked at my code, fixated on a small hack I added at the end just to test, ignored two of the claims and attacked the weakest one in isolation.
They tell me I don’t understand the code. I’m so happy to have https://ourkitty.love/ now as an alternative