4 ms·

Yes, for the reasons you describe, you can't be both a useful web-like protocol and also 100% immutable/hash-linked. But there's a lot middle ground to explore

Yes, for the reasons you describe, you can't be both a useful web-like protocol and also 100% immutable/hash-linked. But there's a lot middle ground to explore here. Loading a modern web page involves making dozens of requests to a variety of different servers, evaluating some javascript, and then doing it again a few times, potentially moving several Mb of data. The part people want, the thing you don't already know exist, it's hidden behind that rather heavy door. It doesn't have to be that way. If you already know about one thing (by its cryptographic hash, say) and you want to find out which other hashes it's now associated with--associations that might not have existed yesterday--that's much easier than we've made it. It can be done: - by moving kB not Mb, we're just talking about a tuple of hashes here, maybe a public key and a signature - without placing additional burden on whoever authored the first thing, they don't even have to be the ones who published the pair of hashes that your scraper is interested in Once you have the second hash, you can then reenter immutable-space to get whatever it references. I'm not sure if there's already a protocol for such things, but if not then we can surely make one that's more efficient and durable than what we're doing now.

XorNot 2y ago
But we already have HEAD requests and etags. It is entirely possible to serve a fully cached response that says "you already have this". The problem is...people don't implement this well.
- __MatrixMan__ 2y ago
  People don't implement them well because they're overburdened by all of the different expectations we put on them. It's a problem with how DNS forces us to allocate expertise. As it is, you need some kind of write access on the server whose name shows up in the URL if you want to contribute to it. This is how globally unique names create fragility. If content were handled independently of server names, anyone who cares to distribute metadata for content they care about can do so. One doesn't need write access, or even to be on the same network partition. You could just publish a link between content A and content B because you know their hashes. Assembling all of this can happen in the browser, subject to the user's configs re: who they trust.

XorNot 2y ago

But we already have HEAD requests and etags. It is entirely possible to serve a fully cached response that says "you already have this". The problem is...people don't implement this well.

__MatrixMan__ 2y ago
People don't implement them well because they're overburdened by all of the different expectations we put on them. It's a problem with how DNS forces us to allocate expertise. As it is, you need some kind of write access on the server whose name shows up in the URL if you want to contribute to it. This is how globally unique names create fragility. If content were handled independently of server names, anyone who cares to distribute metadata for content they care about can do so. One doesn't need write access, or even to be on the same network partition. You could just publish a link between content A and content B because you know their hashes. Assembling all of this can happen in the browser, subject to the user's configs re: who they trust.