The ability to selectively respond to DNS requests is integral to the function of DNS. The only real issue here is that there isn't a standard response code indicating the reason for not returning the record like there is in http
Peering isn't Sender Pays, Peering is "I'll carry your traffic if you'll carry mine", with the understanding that when there's an imbalance in one direction or another that an exchange of some sort is had, be it dollars, bandwidth limits, or similar. In this case, where C interconnects with A which interconnects with B, if C's traffic is so substantial that it's saturating the crosslink between A and B, A would need to evaluate whether their peering agreement with C means that C needs to be paying for the network upgrade, or if there's enough traffic moving from A's network into C's to offset that, and that the interconnect between A and B is the root issue. In your example, rather than paying more into ISPs and, essentially, indirectly funding US network backbone infrastructure upgrades across the board, they solved their problem with cache servers that they handed out like candy to avoid their costs to C sky rocketing. G solved this problem by buying a bunch of dark fiber which was laid on spec by contractors and started peering directly with the Tier 1 providers, dramatically reducing their cost delta.
Where Korea's system differs is that in traditional Tier 1 peering, as I understand it, T's ISP (call them P) should be using some of the money they get from T to pay Q and R for the excess traffic of their customer, but instead Q and R were, per the government, allowed to also charge T for delivery of their packets, resulting in T having to pay both on the up and downlink side, charging them twice for the same bit. T, rather than attempt what G did, told Korea to pound sand and exited the market.
The correct answer in that scenario is C should be paying for it, as in the stated scenario C's traffic would be exceeding the peering arrangement with B and/or A, but there were/are a number of reasons that breaks down in the real world.
I think of it like a bid for the work order. In fact, I think I read somewhere that that's explicitly how it works for instacart: the tip values are shown before the insta employee/contractor picks up the job, and they're encouraged to only take the ones that pay worth their time.
I always figured it was intentional but for the other reason: screws soft enough that overtightening can't damage/crack the multi-thousand dollar components, the screw head cores out first.
Facts. His claim of there being no performance impact is especially dubious because A) he didn't actually remove it, he bypassed an authentication step and B) The 'only checks every few seconds and at level loads' is only the parts he definitively recognized as part of denuvo. At best, he only proved that denuvo removed by a 3rd party is no more a performance hit than leaving it running, and it's more likely that all he proved is that this method of bypassing denuvo provides no performance gains. I'm sure it was neat as a project, but this comes off to a 3rd party like some 'we investigated ourselves and found no wrong doing' shit.
Yeah, identity is a real problem, but someone posted a proposal to solve for that that looks perfect for this sort of thing. Wish I remembered what it was called, but basically each account could attest for the others via export of encryption keys/signatures so while you has multiple 'accounts' there was only one identity which was pointed to in the signature blob.
The tricky part would be getting everyone (matrix, lemmy/kbin/mbin, pixel fed, and masto) to conform to a single identity standard. If one existed, I could see them implementing it, but we're not there yet.
I can sort of see why a chat client wouldn't have a use for activitypub/federation, with the possible exception of identity sharing once that starts to take off.
Could you imagine if the thing that kills HOAs ended up being liability for the actions of their members?
Go Ralph go!