6 ms·

Naming Things with Hashes

42 points by vr000m 14y ago

antidoh 14y ago
This seems like it could lead to (among other things) a non-third party scheme for link shortening.
- shabble 14y ago
  The limiting factor there is primarily the domain name length, rather than the specific content reference, or at least the thing least easily changeable.
a-priori 14y ago
I'm seeing the beginnings of a replacement for HTTP based on a distributed hash table.
- barrkel 14y ago
  You may be interested in this Google Tech Talk from 2006 - http://www.youtube.com/watch?v=oCZMoY3q2uM http://www.youtube.com/watch?v=oCZMoY3q2uM . I found it interesting at the time it came out.
  - vdm 14y ago
    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 http://news.ycombinator.com/item?id=3847968 1. https://www.ccnx.org/wiki/CCNx/CCNxPresentations https://www.ccnx.org/wiki/CCNx/CCNxPresentations
- TazeTSchnitzel 14y ago
  You mean like Freenet? :)
inghoff 14y ago
For human-friendly URIs, I would've liked to see Doug Crockford's Base32 encoding (http://www.crockford.com/wrmg/base32.html http://www.crockford.com/wrmg/base32.html) instead of hexadecimal. Case-insensitive, but still more compact than hex.
- deleted 14y ago
  [deleted]
- efsavage 14y ago
  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.
- gojomo 14y ago
  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 http://tools.ietf.org/html/rfc4648#section-6). For comparison, the digits sets for 0-31 are: RFC4648-b32: ABCDEFGHIJKLMNOPQRSTUVWXYZ234567 RFC4648-b32he: 0123456789ABCDEFGHIJKLMNOPQRSTUV Crockford-b32: 0123456789ABCDEFGHJKMNPQRSTVWXYZ 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).
emilis_info 14y ago
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 https://www.ietf.org/rfc/rfc2396.txt Also: "nih" sounds like a pun :-)
- idupree 14y ago
  "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#section-8.1 https://tools.ietf.org/html/draft-farrell-decade-ni-10#secti... )
beagle3 14y ago
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.com/mnemonic/ http://web.archive.org/web/20051109230247/http://www.tothink... http://web.archive.org/web/20051109233255/http://www.tothink.com/mnemonic/wordlist.html 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.
- dfc 14y ago
  PGP had a nice wordlist for verifying key fingprints: http://en.wikipedia.org/wiki/PGP_word_list http://en.wikipedia.org/wiki/PGP_word_list
- svag 14y ago
  There is a C source code in github, https://github.com/singpolyma/mnemonicode https://github.com/singpolyma/mnemonicode. I haven't tested it though to see if it's working.
Xymak1y 14y ago
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 14y ago
  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."
peterwwillis 14y ago
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://en.wikipedia.org/wiki/Universally_unique_identifier https://tools.ietf.org/html/rfc4122 https://tools.ietf.org/html/rfc4122
- snprbob86 14y ago
  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 14y ago
    How is that different from UUID version 3 and 5, which both use hash values? https://en.wikipedia.org/wiki/Universally_unique_identifier#Version_5_.28SHA-1_hash.29 https://en.wikipedia.org/wiki/Universally_unique_identifier#...
    - snprbob86 14y ago
      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 14y ago
        Also by my reading the UUID conventions are hashes of other names to make them fit the UUID format... not hashes of specific content.

42 points by vr000m 14y ago

antidoh 14y ago

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

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

a-priori 14y ago

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

barrkel 14y ago
You may be interested in this Google Tech Talk from 2006 - http://www.youtube.com/watch?v=oCZMoY3q2uM http://www.youtube.com/watch?v=oCZMoY3q2uM . I found it interesting at the time it came out.
- vdm 14y ago
  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 http://news.ycombinator.com/item?id=3847968 1. https://www.ccnx.org/wiki/CCNx/CCNxPresentations https://www.ccnx.org/wiki/CCNx/CCNxPresentations
TazeTSchnitzel 14y ago
You mean like Freenet? :)

inghoff 14y ago

For human-friendly URIs, I would've liked to see Doug Crockford's Base32 encoding (http://www.crockford.com/wrmg/base32.html http://www.crockford.com/wrmg/base32.html) instead of hexadecimal. Case-insensitive, but still more compact than hex.

deleted 14y ago
[deleted]
efsavage 14y ago
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.
gojomo 14y ago
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 http://tools.ietf.org/html/rfc4648#section-6). For comparison, the digits sets for 0-31 are: RFC4648-b32: ABCDEFGHIJKLMNOPQRSTUVWXYZ234567 RFC4648-b32he: 0123456789ABCDEFGHIJKLMNOPQRSTUV Crockford-b32: 0123456789ABCDEFGHJKMNPQRSTVWXYZ 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).

emilis_info 14y ago

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 https://www.ietf.org/rfc/rfc2396.txt Also: "nih" sounds like a pun :-)

idupree 14y ago
"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#section-8.1 https://tools.ietf.org/html/draft-farrell-decade-ni-10#secti... )

beagle3 14y ago

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.com/mnemonic/ http://web.archive.org/web/20051109230247/http://www.tothink... http://web.archive.org/web/20051109233255/http://www.tothink.com/mnemonic/wordlist.html 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.

dfc 14y ago
PGP had a nice wordlist for verifying key fingprints: http://en.wikipedia.org/wiki/PGP_word_list http://en.wikipedia.org/wiki/PGP_word_list
svag 14y ago
There is a C source code in github, https://github.com/singpolyma/mnemonicode https://github.com/singpolyma/mnemonicode. I haven't tested it though to see if it's working.

Xymak1y 14y ago

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 14y ago
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."

peterwwillis 14y ago

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://en.wikipedia.org/wiki/Universally_unique_identifier https://tools.ietf.org/html/rfc4122 https://tools.ietf.org/html/rfc4122

snprbob86 14y ago
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 14y ago
  How is that different from UUID version 3 and 5, which both use hash values? https://en.wikipedia.org/wiki/Universally_unique_identifier#Version_5_.28SHA-1_hash.29 https://en.wikipedia.org/wiki/Universally_unique_identifier#...
  - snprbob86 14y ago
    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 14y ago
      Also by my reading the UUID conventions are hashes of other names to make them fit the UUID format... not hashes of specific content.