@lina I meant "a god", not "the God", @StumbleDonkey is correct. What shared waifuism creates is but an egregore, among many just like it, for someone who would take anything to fill that spiritual void. Though @Dullahan probably lacks the God too, considering a laifu-destroying harem he has acquired.
@Dullahan@lina Certainly. But you already know that, very few touhou characters have a hope even for resemblance of obscurity, much less the poster girls.
@lina@Bobetap@FrailLeaf@mint@sigmaeye Which is what I've been proposing. You have the list of their ap_ids if you want automate things, but I'd suggest going for most active and vocal of their users, which would reduce the amount of work required first, as they're most likely to harass their own admins about bad Russian hackers devising their whereabouts by IPs or something.
@lina@Bobetap@FrailLeaf@mint@sigmaeye I'm all for removing the reason for them appearing on Eientei if they just want pawoo and baraag, but any doxing of local users with administrative resource is not something I could justify, there should be no need once instances above block Eientei.
@lina@Bobetap@FrailLeaf@mint@sigmaeye Such list is a dox in itself when taken for local users, as it includes even those that never interacted with anything, much less publicly federated. If I start providing some internal information of Eientei users - this by implication turns Eientei into honeypot and I do not want that. Users must bully and dox each other as regular users.
> i was just intending on regularly putting them into hellthreads so they suffer until they literally block everyone except pawoo and shit That would not stop new ones from appearing, as content they're for still arriving, and they could just disable mention notifications.
> now to get baraag and pawoo to defederate from us, we'd need to actually act like niggers and consistently create issues for pawoo and baraag Correct.
> their posts would still end up reaching us unless we unsubscribe from relays that federate that shit to us A valid observation, but it should already reduce volume to only that is relayed, and relays could be handled separately.
@lina@FrailLeaf@Bobetap@mint@sigmaeye I don't remember saying this, but in general I prefer free-for-all deathmatch than to hide and cover in private lounges and so long they don't post 3DPDs or mindlessly spamming, bullying and non-administrative doxing should be sufficient warding for local users, they are the consequence rather than the cause of the issue. Systemic solution would be to convince braarg/pawoo to defederate, a mild wide-scale doxxing attempt on their users has very good chances of doing it, if it riles at least some of them to actually poke whatever administration they have, but you already got the tools and more importantly - time and attention to whatever is happening on fedi to implement that, not sure what you are waiting for to actually make use of it.
@Pawlicker@mint@Zergling_man If you want to go other way around and actually run the thing instead of scaring it away, you may need to also hide the vmexit counters, https://github.com/WCharacter/RDTSC-KVM-Handler provides clue on how, though a bit outdated. https://github.com/a0rtega/pafish is nice to test how well your VM is hidden, though in qemu case you may need to patch a bunch of device strings and add some temperature/voltage sensors, so hardware report would look more realistic.
@mint@Pawlicker@Zergling_man With one simple trick you can ward off 90% of copy protection and anticheat systems. A client-side validation crutch developer fears self-signed kernel modules.
@lina@mint@puckipedia This would prevent caching/reusing same object when federating. For proper function, both proactive federation queue and on-demand object lookup must be instrumented.