@disarray they're talking about the emoji stealer MRF that was mostly broken, so the RCE would have required an admin to set it up with a whitelist to a malicious instance, whose admin would later add a malformed emoji to replace something like the inbuilt captcha binary
@mint@not_benis@crunklord420 you don't even have to go into virtualization, my rx 6800 would hang every other day on a failed reset until i gave up and started using compiz
@mint reached the same conclusion reading over the code, i'll still do the RemoteFetcherWorker bit just so there's a retry to ddos flaky instances even further
@mint maybe it's just natural overlap on the non pleroma relays i've noticed, since i can see some stuff getting fetched more than a dozen times, still seems to be working fine, i'll refine it a bit later in the morning, but your version as is seems good enough for most
@mint :reject feels like asking for redelivery amplification trouble, there really should just be a silent drop option :drop where it lies that the activity was accepted without error
but yes, mrf works best when the rest of the codebase is a mess
@mint run an analyze if you haven't, but at some point you have to give up and scale the shit heap vertically (less work or more dakka)
remember pleroma will only pool 20 connections by default, so not spawning too many idle worker forks is a good idea, since they'll just eat up ram and spread the cache thin in the pgtune math
you could go down to 20+20+5 and be fine probably, since no amount of extra queries waiting on IO will help get rid of the underlying stall