18 ms·

Is there more information on the intended application domain (use cases) ? This was unclear for me after reading your referenced document. Most of your argumen

by chmike 11y ago

Is there more information on the intended application domain (use cases) ? This was unclear for me after reading your referenced document. Most of your arguments apply to hash referencing and make perfect sense to me. The compatibility with URI is also a good point and not difficult to achieve. I would add that compatibility with URL (http scheme) is also desirable and may be solved by use of a protocol bridge so that the information is accessible to web applications. I'm also working on a distributed information system for many years now (not full time;). But I use a different referencing system. The reason is because one can't modify the information without invalidating the hash and thus the references. So using hashes as reference make sense for a system containing only immutable information. Your choice of reference is thus very application specific. The system I'm working on allows to modify and move data without invalidating references and is distributed like the web. A reference is at most 32 byte long in its binary representation, a bit longer in its ASCII representation. Take that http! ;)

btrask 11y ago
I believe there is a fundamental distinction between URI schemes that are dynamic but centralized (meaning they require some form of coordination, to handle mutability), versus schemes that are static and decentralized (for example, they are defined by a hash algorithm that anyone can run independently). If you go the dynamic/centralized route you end up with something like the World Wide Web, which already works very well for that use case. Content addressing will never be useful for things like online shopping, where your requests are basically remote procedure calls. Instead I think it's good for publishing, sharing files, and things like that. I do have a plan to build mutability on top of StrongLink eventually, using diffs like Git. I think it's important to have a clean separation, so that the sync protocol stays simple and impossible to get wrong. The initial application for StrongLink is notetaking, which I find much easier to do with immutability. It's like writing in ink.
- chmike 11y ago
  To support mutability you would need redirections so that you can access to the most recent version with an old reference. The problem with that is that you can't check the validity of a redirection as you can do with a returned file. Thus hash references work in a secure and trusted environent.

by chmike 11y ago

btrask 11y ago

I believe there is a fundamental distinction between URI schemes that are dynamic but centralized (meaning they require some form of coordination, to handle mutability), versus schemes that are static and decentralized (for example, they are defined by a hash algorithm that anyone can run independently). If you go the dynamic/centralized route you end up with something like the World Wide Web, which already works very well for that use case. Content addressing will never be useful for things like online shopping, where your requests are basically remote procedure calls. Instead I think it's good for publishing, sharing files, and things like that. I do have a plan to build mutability on top of StrongLink eventually, using diffs like Git. I think it's important to have a clean separation, so that the sync protocol stays simple and impossible to get wrong. The initial application for StrongLink is notetaking, which I find much easier to do with immutability. It's like writing in ink.

chmike 11y ago
To support mutability you would need redirections so that you can access to the most recent version with an old reference. The problem with that is that you can't check the validity of a redirection as you can do with a returned file. Thus hash references work in a secure and trusted environent.