NBnbadg·Jul 31, 2015
I agree that hash-based addressing creates a bit of a chicken-and-the-egg problem for content discovery, with the exception of, for example, existing links or QR codes. You'll always need some way of looking up the hash for the content you're hoping to find. But that lookup mechanism need not be a single centralized service. In fact, I would make the argument that in many cases, search engines are doing exactly this right now: you have several coexisting, competing, but centralized services, and a user is free to choose between them. It's centralization, sure, but in a much more robust way (though it admittedly could be significantly improved through, for example, a common search API). The only difference is that contemporary search engines are looking up URLs instead of hashes, but given how we're using URLs these days (ex: https://imgur
Read the rest
.com/iauyhdf), I don't think it's a big distinction.
You're also spot-on that dynamic content is the hardest part of hash-based addressing, but the problem is a bit more nuanced IMO. On the one hand, all content, once created, is static. If a thermometer reads 32.8 at 15:40 on 30 July 2015, that data point is fixed in time, immutable. However, we humans think of things far more conceptually, and we build cognitive connections between things. All content is static, but all concepts are dynamic. So the question is then, how do you reconcile those two?
The best answer I've personally come across is bindings -- exactly analogous to binding names to variables in Python. Some hash bindings would be static, some bindings dynamic. That also allows you to construct more complicated objects like buffers natively. That's how I'm doing it in the project I'm working on (https://github.com/Muterra/doc-muse), though the bindings are a relatively new addition that I haven't had time to test yet (or update the documentation, for that matter).