This is a really interesting thread! I did want to touch base on the InfoCentral “technical properies of decentralised information” article, because I think the answer there is actually more nuanced than that.
I don’t see Holochain as satisfying those criteria natively- it’s too flexible. Until we have an application standard for RESTful data representation, we don’t have proper content-based addressing. In fact, in Holo-REA we have deliberately broken some of those constraints, for multi-network complexity reasons (hash-based addressing has complications, because IDs change).
Not to suggest that I think that’s good. There’s a user story we are missing a solution for, which I think could be addressed by realigning with some of these principles:
As a participant within a target network, I should be able to determine when an external record has linked into my network. I should also be able to determine when an external linker has not followed update protocol within my network- i.e. an external record has been updated (hash changed), but they haven’t notified my network of the update.
This could be achieved with metadata being included in responses, or a dedicated zome API for inspecting record versions. But ideally, if you request stale data from a network it would still return the data at that version, along with hashes of subsequent revisions that can be used to retrieve those versions. Currently in Holo-REA we have a persistent ID for a record between updates, because it was the easiest way of solving this user story at the time:
As a participant within a network, I should be able to determine how many distinct external records are linking to records stored within my network space.
I think proper handling of revision metadata and version-anchored hashes would allow us to have the best of both these worlds…