I'm aware of that; just taking the opportunity to point out that C++ files on UNIX systems can use extensions other than those you mentioned, and in particular that the one bit of C++ in the Linux kernel repository uses the .cc extension.

Actually, you are only just now taking that opportunity. I appreciate the correction and additional information. In fact, that is exactly why I said I wanted to challenge the assertion, rather than saying there definitely isn't any.

Fair enough; I should know better than to post command executions or code snippets as comments without further explanation of their significance. Thanks for calling me on it. :)

I'm aware of that; just taking the opportunity to point out that C++ files on UNIX systems can use extensions other than those you mentioned, and in particular that the one bit of C++ in the Linux kernel repository uses the .cc extension. You also didn't cover the .C extension, though that one doesn't see much use due to incompatibility with case-insensitive systems.

~/src/linux-2.6$ find -name '*.cc'
./scripts/kconfig/qconf.cc

How can somebody be biased against an objective fact with proper authoritive references supporting it?

You've attempted to apply rational logic to biases, but biases don't subscribe to logic; they represent bugs in rationality.

There's no such thing as an "entrance node" in Tor; the first hop is encrypted, and at most the first node you contact can say "the system talking to me uses Tor". While that may cause you some problems in environments that prohibit use of Tor entirely, Tor doesn't have that as a security goal; Tor just ensures that nobody can figure out both endpoints, and it does that quite well as long as no one entity can control a significant fraction of the nodes on the paths you use.

As for trust, you generally have to trust *someone* in a system, but you want to reduce the number of trusted entities to the minimum. For instance, when talking to example.org, you ideally only want to trust example.org to provide the content you expect; you shouldn't also have to trust "org" and the root to not take over the site.

That doesn't mean you want naming by consensus, either; that could have the "everyone on the Internet is lying to you" problem you described.

DNS (perhaps with DNSSEC) might even remain a reasonable protocol to use on individual domains, such as to allow "example.org" to provide "www.example.org" and "planet.example.org". However, having a central "org" registry with control over "example.org" puts control in the wrong place, and allows abuse.

Doesn't really help; browsers have bookmarks already. That doesn't solve the problem of helping users get to a site from some well-known name. And IP addresses aren't as stable as names.

There's no reason for DNS resolution to go through any centralised server. Use a distributed hash table to publish and retrieve records and sign them. Of course you'd still need a central authority to issue and sign certificates.

That decentralizes the boring bit of the problem. You still have to trust the central authority to not abuse their power, and that doesn't work.

Using public keys as addresses would be pretty sweet, but how do you route traffic through a network with randomly distributed addresses? Ad-hoc routing can work on small scales, but there'd be serious issues making a global network like that.

That's actually an easier problem, known as "location-independent identifiers". Most ad-hoc routing protocols tend to flood-fill the network, either when calculating routes or when routing packets. However, ad-hoc routing protocols do exist that avoid flooding, and those protocols can scale.

Virtual Ring Routing can handle Internet-scale networks by treating them like small-world networks, using the same mechanism distributed hash tables use: treat the addresses as a ring, and use a combination of your physical neighbors and your "virtual" neighbors on the ring to cross long distances. A later paper on VRR showed that it scaled quite well with the size of the network, both in the expected length of the routing path and the expected number of routing table entries needed on each node.

We got a team of students to develop an implementation of VRR for Linux, and Microsoft Research has an implementation for Windows.

So yes, we can solve the routing problem easily enough. We just need some way to handle naming that the general public will put up with.

Why continue with the concept of name ownership at all? It should be technically impossible to own a name, in the same way that it should be impossible to monopolize ideas.

Let people and entities use whatever name they want; the remaining problem is to verify that you are talking to the right host, but you should need to do that anyway. Invariably, any sort of central authority can and will be subverted. What is necessary is some other means of conveying trust, wether that is a web of trust, or some other out of band option.

I'd gladly use a system like that. You can trivially "name" systems using their public key fingerprints, which then just means you need to *find* those sites. Right now, people find those sites three ways: they use a search engine like Google and get a link (not a problem), they follow a link from another site (not a problem), or they type in an address (problem). To handle that last one, note that the address has to come from somewhere; that source could always provide things like QR codes or other mechanisms to identify a particular address without having to enter the whole thing.

Good luck migrating from the existing system, though.

For starters mirror the current root dns but refuse to remove any domains if they were tampered with by the RIAA and the like.

Remove all squated/harvested domains. (It's easy detect those), smarter people could think of what's next but this is a pretty good start.

That wouldn't solve the problem; that would just move control from a group that *definitely* shouldn't have it to a group that would make it marginally better in a few narrow cases. I said "decentralized" because I'd like to see a system where *nobody* has that control. I don't just want to see a centralized system with a different center.

I think you missed the point; I didn't give a "definition", I gave a few examples to make the point that P2P systems and security can indeed go together. The post I replied to seemed to have the impression that P2P and security didn't mix.

Many secure peer-to-peer systems exist, generally based on cryptography; often they provide more security than centralized systems.

For instance, Tor uses secure cryptography to provide anonymity in a way that just wouldn't work in a centralized system. i2p uses cryptographic security as well.

On the one hand, I absolutely want to see control over domain names taken out of anyone's hands (not just ICANN's).

However, decentralized naming is a *hard* problem. Only one entity can control a given domain name, and something, either human or automated, must decide who gets that domain name. Whether by fiat or general consensus, some process must exist to handle the case where multiple people want the same name. ("First come first served" does not suffice unless you have fees or some other measure to prevent mass registration, and decentralized control makes those measures difficult.)

(Numbers, by comparison, prove quite trivial; just use public keys. But people don't like typing in long numbers, they like typing in *names*.)