And if you want it to be pronounceable, why not use Oren Tirosh's Mnemonic Encoder?
About 10 years ago, Oren Tirosh published "mnemonicode", which was a selection of 1600 words which were optimized to be (i) internationally recognizable, and (ii) have distinctive pronunciation that would survive a low-quality phone medium and/or a non-native speaker.
I can only find a copy in the wayback machine now:
For human-friendly URIs, I would've liked to see Doug Crockford's Base32 encoding (http://www.crockford.com/wrmg/base32.html) instead of hexadecimal. Case-insensitive, but still more compact than hex.
Another handy trick is to drop vowels, which only costs 6 characters (with y), and greatly reduces the chance that your url will include a noticeable profanity or other undesirable word.
The problem with Base32 encodings is that there are so many of them. (I say this as a fan who promoted Base32 in a number of uses, and wish the proliferation of encodings could have been avoided.)
For example, Crockford's is different from both of the variants defined in IETF RFC 4648 (http://tools.ietf.org/html/rfc4648#section-6). For comparison, the digits sets for 0-31 are:
There are even others. Each had locally-reasonable reasons for their variation at the time.
I used the 1st row approach, in the SHA1 identifiers at Bitzi and in the original 'magnet:' proposal, because it had also been documented in an earlier IETF RFC for other purposes, and is perhaps best for anyplace where human sight-reading/handwriting could confuse certain digits. But the 2nd-row variant is easiest for encoding/decoding, and the 2nd/3rd row variants have some sorting benefits (the encoded versions sort in the same order as the raw binary versions).
That's Van Jacobsen introducing CCNx Content Centric Networking. One way I would summarise it is as a stripped down HTTP at Layer 3. Just think about all the client devices out there that don't actually need IP addresses or the management overhead going with them. After watching this I concluded that IPv6 is an IETF solution to The Wrong Problem (more! faster!). I can't understand why Google would prioritise SPDY over this, they could make Chrome do CCNx over IP to their DCs instead.
It's an outstanding talk, I've watched it 3 times now since I found it [0] on HN a few months ago. VJ is a visionary and a gentleman.
The FISS09 workshop presentation [1] is about 3 hours, well worth it for a deeper dive. His tour of the history of how packet switching emerged in a telephony circuit dominated industry is a fascinating case study on introducing fundamental change to a legacy incumbent system, as well as the early history of data networking.
Correct me if i'm wrong, but don't UUIDs already provide all this (except for the human-friendly aspect)? Expanding past 128 bits should probably be included in the next version.
You're wrong. UUIDs don't provide any guarantees about the target of the reference.
ie. Given a UUID, and a service endpoint which returns some data for a given UUID, the client has no way of ensuring that the data returned from the service is in fact what they asked for. A similar service operating on hash values would have the property that clients can run the same hash algorithm locally to ensure that the server isn't lying to them.
Names of a namespace, yes, but standards were meant to be broken. It doesn't really matter what you based the hash on, it's up to the application(s), much like the type of UUID you choose.
The reason I like UUID better is (once you pick a version) it's simple. It already looks pretty readable and it's a well known widely-used standard. It would have been nice if the authors of this RFC had just expanded on UUID. People are also way too URI-obsessed; when are you going to pass this hashed URI to an application? IMHO an object reference should be just that and not involve application interfaces.
In terms of the hashing algorithms, (IIRC) unless you're using HMAC you're opening yourself to an (eventual) brute force and key reuse issue, or at the very least the potential for an implementer to ignore the need for a random salt and get either easy collisions or predictable table insertion. I would feel pretty nervous if the hashing algorithm was my SPF.
But unless you rigorously enforce the hash=name convention, you can't get its benefits. (Benefits like stability and implicit verification.) And shoehorning the hash into the constrained UUID format hides/confuses the conventions you're committing to.
If you name is a hash, and really needs to be a hash, that should be evident, not squeezed into the bitfields of a 'UUID'.
Avoid things like "Dearest Receiver, please view the transfer and customs documents at scam.ly/DEADBEEF to assist in transferring 3 gold bars from my late cousin's vault."
The limiting factor there is primarily the domain name length, rather than the specific content reference, or at least the thing least easily changeable.
About 10 years ago, Oren Tirosh published "mnemonicode", which was a selection of 1600 words which were optimized to be (i) internationally recognizable, and (ii) have distinctive pronunciation that would survive a low-quality phone medium and/or a non-native speaker.
I can only find a copy in the wayback machine now:
http://web.archive.org/web/20051109230247/http://www.tothink...
http://web.archive.org/web/20051109233255/http://www.tothink...
But if we're adding a way to "name things", I think over-the-phone naming should also be considered.