Thank you very much for introducing the terms handle (my "PUI"s are just handles) vs. name.
I will use those terms from now on, as they seem to be widely used and understood.
the handle could actually map to something non-IP
To be fair, it seems that DNS could just as well map names to more than IP addresses. But a separation of handles from names probably reduces the baggage accompanying such a move. As we consider table entries other than IP addresses, we should avoid providing information that can just as well be obtained from the IP address, and also services (such as authentication) that are best handled end-to-end. But UDP style addresses (IP address plus port address), and even somewhat richer addresses that include parameters to pass to the application at the given port, are probably worthwhile, since they allow more separation of authority within an individual physical host. Hunt groups (lists of IP addresses to try) are probably worthwhile, since we need the later addresses precisely when we can't reach the first one. I'm sure that there are other possibilities, and there's no need to cut any of them off at the beginning.
To dereference the domain name www.bradneuberg.love, for example, you would first need to contact the Naming Service and get the handle, such as 23423423. Then you would need to contact the Handle Service and get the actual IP address or service endpoint. Latency latency latency, which already plagues DNS, would get you as well,
I don't think so. Handle resolution, by itself, should have essentially the same latency as DNS name resolution does now. Most name resolution services other than DNS now map to domain names (used, in this case, as handles). They can map to handles with no increase in latency. At first, the current DNS will work side-by-side with the new handle service---no lextra latency there. If the DNS switches to mapping names to handles, instead of names to IP addresses, most applications will store pointers to handles, rather than to names. The current cacheing of domain names is done mostly for their value as handles, not for their value as names. Handles will be very stable, and will be redirectable to different IP addresses over time. This reduces (dare I hope, nearly eliminates?) the need to refer repeatedly to the same name to find out whether it points to a new handle. Also, DNS tables can cache IP addresses to reduce and amortize the cost of refreshes from the handle-to-IP tables. They already know how to do this, since it's essentially the same thing as cacheing table entries in a local name server.
I am personally building a naming system that is distributed (its called the Distributed Domain Name System) and which runs above peer to peerj
Please post pointers to anything that you've written about this. So far, I haven't conceived of a peer-to-peer implementation of handle mapping. It seems that I need a central authority to avoid collisions at the top level. And lower levels are handled hierarchically just like DNS does it. But I definitely want to minimize the need for central authority, and if you know how to crank it even lower, please share.
You also have the problem of maintaining the storage space for these two sets of tables, Name to Handle and Handle to Service Endpoint. That would mean squaring the size of the existing DNS system
I don't see why the table size squares. I think that handle tables are approximately the same size as name tables. So, the new handle system merely adds another set of tables equal in size to the current DNS tables. I am a bit worried that, because handles are so much cheaper than names, the demand goes up too fast for the administrators to deal with it by distributing subranges of the key space. But that's the sort of problem I'd love to deal with, since it means empowering lots of little guys with their own handles.
The other issue is more abstract. TBL (Tim Berners Lee) has the dream of everything being addressable through URIs, because if something has an address, "we can talk about it." So when I create a tag library in XML for my newspaper, lets say the Newspaper Markup Language, and have the tag , this tag actually derefences to the full URI http://mynewspaper.org/NewspaperMarkupLanguage/Article.
How would this scheme of everything as a URI tie into a Handle scheme? Would that URI above actually be some handle, 213423423? It seems messy.
Well, I do see the likelihood of mapping handles to more and more flexible types of values. The ability to give out handles so promiscuously probably increases the incentive to do this. But I don't see any reason to work this out up front. The handle-to-IP service seems very valuable by itself. Why not do it, then see what we think of next? We'll have the choice to add more functionality to the handle system, or to let other functions be implemented separately. An increase in the types of things that are handled (i.e., referred to by handles) in a uniform way usually looks attractive. But it's not hard to prove that, however many things have handles, we start manipulating some that don't.