
Naming Things with Hashes - vr000m
http://tools.ietf.org/html/draft-farrell-decade-ni
======
beagle3
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:

[http://web.archive.org/web/20051109230247/http://www.tothink...](http://web.archive.org/web/20051109230247/http://www.tothink.com/mnemonic/)

[http://web.archive.org/web/20051109233255/http://www.tothink...](http://web.archive.org/web/20051109233255/http://www.tothink.com/mnemonic/wordlist.html)

But if we're adding a way to "name things", I think over-the-phone naming
should also be considered.

~~~
dfc
PGP had a nice wordlist for verifying key fingprints:

<http://en.wikipedia.org/wiki/PGP_word_list>

------
inghoff
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.

~~~
efsavage
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.

------
emilis_info
I don't understand the need for "//" in the URI. The thing that follows it is
usually an authority (hostname), not a name for an algorithm.

This would still be a valid URI without the unnecessary characters and without
the confusion:

    
    
        ni:sha-256;UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q
    

See: <https://www.ietf.org/rfc/rfc2396.txt>

Also: "nih" sounds like a pun :-)

~~~
idupree
"Authority The optional authority component may assist applications in
accessing the object named by an ni URI." They give this example:

ni://example.com/sha-256;f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk

( [https://tools.ietf.org/html/draft-farrell-decade-
ni-10#secti...](https://tools.ietf.org/html/draft-farrell-decade-
ni-10#section-8.1) )

------
a-priori
I'm seeing the beginnings of a replacement for HTTP based on a distributed
hash table.

~~~
barrkel
You may be interested in this Google Tech Talk from 2006 -
<http://www.youtube.com/watch?v=oCZMoY3q2uM> . I found it interesting at the
time it came out.

~~~
vdm
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.

0\. <http://news.ycombinator.com/item?id=3847968> 1\.
<https://www.ccnx.org/wiki/CCNx/CCNxPresentations>

------
peterwwillis
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.

<https://en.wikipedia.org/wiki/Universally_unique_identifier>
<https://tools.ietf.org/html/rfc4122>

~~~
snprbob86
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.

~~~
peterwwillis
How is that different from UUID version 3 and 5, which both use hash values?

[https://en.wikipedia.org/wiki/Universally_unique_identifier#...](https://en.wikipedia.org/wiki/Universally_unique_identifier#Version_5_.28SHA-1_hash.29)

~~~
snprbob86
My apologies. You're correct: I mistakenly equated UUID with UUID v4.

That said, the difference with this new proposal appear to include at least
the following:

1) Support for untruncated hashes

2) More secure hash algorithms

3) Extensibility to new hash algorithms

4) URI compatibility

~~~
gojomo
Also by my reading the UUID conventions are hashes of _other names_ to make
them fit the UUID format... not hashes of specific content.

~~~
peterwwillis
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.

~~~
gojomo
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'.

------
Xymak1y
What is the practical application of this? As opposed to a generic link
shortener? I mean how is a 32-bit hash better than just using bit.ly/Nx7ax1?

~~~
antidoh
No third party required.

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."

------
antidoh
This seems like it could lead to (among other things) a non-third party scheme
for link shortening.

~~~
shabble
The limiting factor there is primarily the domain name length, rather than the
specific content reference, or at least the thing least easily changeable.

