@liw I agree with you, though this is a bit trcky:
> and you must have a way to migrate to newer, stronger algorithms.
Can you elaborate on this?
I'm thinking specifically about Datashards. We do have a mechanism to change from one algorithm to another, but we can't automatically migrate data.
@emacsen The usual approach to doing that seems to be to allow N algorithms, and allow each message/commit/thing use any of them, or even several.
For example, PGP specifies a list of acceptable encryption algorithms, and each message can use any of them. The original ones from the early 90s have all been deprecated and dropped from the approved list, so modern messages are more secure than a message created in 1991 would be now.
I should look at the Datashard spec some day.
@liw There isn't a formal spec yet. I'm actually working on the pre-spec draft docs yesteday and today.
@emacsen I'm now wondering about using automated tests for specifying protocols by having tests that any implementation of the protocol should pass.
But that's just because I've just spent my holidays writing test tooling.
@liw The challenge here is that Datashards is not a wire protocol, but rather a framework for data format (not even a format in itself) with some components able to talk across the wire to each other in a series of protocols. That's one of the challenges in documenting and testing it.
@emacsen I read the existing Datashards docs that I could find. Very interesting concept.
Not sure I understood everything. For example, is the IDSC URL with the encryption key meant to be private, and only the encrypted shards get shared?
I'd love to help with documenting Datashards, but I'm not sure I have the available cycles in the next few months. But the concept is very, very interesting. I shall be interested in seeing where you take it.
Lars and friends