I obviously know far more about how the Internet and its various protocols work than you do. You keep insisting that there's existing technology that behaves like a local telephone exchange, while simultaneously explaining exactly how there isn't. "iChat can be configured." But it isn't. "Bonjour can be relayed." But it isn't. "UNIX 'write' command lets you send messages to any system you know the address of and have an account on." But I don't have an account on every machine in my neighborhood, nor am I going to get one. "Every webserver implements bidirectional communication." Really? Now are you going to tell me how an ethernet switch works?
DNS is an appallingly centralized system for a decentralized system. It is centralized in the root servers which are all very far away from you (and me) in network terms. Your typical query hits a minimum of 1 server (your service provider's server) and a maximum of 3, since once your ISP's server admits ignorance, you go straight to the root to find the nameserver that knows the domain, then you go to it for the resolution. My typical query hits a minimum of 1 server (the one I run) and a maximum of 4. But with your deep knowledge of how the Internet and its protocols work, you already knew that, right? Oh wait, you obviously didn't, or you wouldn't keep insisting that DNS is a decentralized system. The fact that individual zone files are scattered across thousands of nameservers is irrelevant given the total dependency on the 13 root servers (embodied in 376 actual machines).
If a switch room somewhere gets flooded (a far more common occurrence than zombie apocalypses), cutting my neighborhood off from the root servers, odds are I will have no ability whatsoever to resolve the IPs of my neighbors, businesses nearby, or family in the next town that happens to be on the same side of the network partition, because neither my nameserver nor my ISP's nameserver has cached anything about the domains they're in because more than half of them don't have the same ISP. Which means I can't make a VOIP phone call to most of them, even if my VOIP provider didn't insist on a connection to their central server which I have just lost and therefore have no phone service whatsoever, despite having valid routing to tens of thousands of machines nearby. And my point, which you persistently refuse to acknowledge, is that all current VOIP systems are built this way and are very unlikely to change for both technical and human reasons I have already enumerated.
The protocol you are so fond of, zeroconf, is not "decades" old. It was first implemented 11 years ago, and it was ratified as RFC 6763 this year. And ISPs universally filter it, either directly in the modem's router or in the first router after it, specifically to prevent neighbors seeing each other's zeroconf devices (which they currently don't want to see anyway). More to the point, ISPs universally filter multicast at their edge routers, so something zeroconf-like isn't going to work either. You did know that zeroconf works via multicast, right? That right there is more than sufficient to justify my assertion that this is a hard problem with no current solution. Getting any ISP to change that policy is essentially impossible, for very good technical reasons and some fairly valid business reasons.
So please, enlighten me with your deep knowledge of the Internet and its protocols. Describe this mythical decades-old solution. The one that isn't multicast, that can reliably traverse NAT, that can survive loss of routing to DNS root servers, that can tolerate endpoint devices going offline on a regular basis, that can tolerate the asymmetry of the typical consumer link, that can function in the face of network partitioning at the regional level, and that requires no more technological sophistication on the part of users than subscribing to an account and plugging in an access device. A device we'll call a telephone, in a fit of innovation.