qri-io / registry

MOVED. Registry code now lives at: https://github.com/qri-io/qri/tree/master/registry
MIT License
4 stars 0 forks source link

Add Trusted timestamp support #31

Open b5 opened 5 years ago

b5 commented 5 years ago

In our dev call today the idea of trusted timestamps: https://en.wikipedia.org/wiki/Trusted_timestamping

This would be a great addition to proving that a dataset was created at a specific point in time. The IETF has an RFC on the topic: https://www.ietf.org/rfc/rfc3161.txt

There's even a go implementation: https://github.com/clocklock/go-rfc3161

I think we can sew this process into the registry as a starting point, and surface it as part of an --archival flag on qri save.

This kind of change would merit writing an RFC for how this would work, but let's first gather feedback on how this would work, and who would be interested in having this exist. cc'ing folks who were on the call: @mr0grog, @jlwaugh, @frijol

Generally, I think we should do this, but also, questions:

Finally, as with all things, we'd love for this to end up as a decentralized system. @jlwaugh has already done some writing on this topic & it's intersection with individuals: https://medium.com/@jwaup/everyone-is-multidimensional-2eaf30b1fac9

Should we spend more time in the planning phase & roll this out as a p2p thing from the get-go?

Mr0grog commented 5 years ago

how much we should prioritize building this? Is this vital to use cases like EDGI's

Despite the fact that I think this would be really cool and valuable, I don’t think it’s vital (I could be wrong). At EDGI, we’ve seen cases where it would’ve been nice (in one case, we did an analysis, then the agency said we were wrong, and then they published new numbers that changed the analysis), but in those same cases, we’ve been supported just as well by the level of trust and reputation we’ve built up, and not been totally screwed by not having a provable timestamp.

(From a bigger picture standpoint, I suspect many judicial environments are not technically sophisticated enough to distinguish between a local machine timestamp and a signed one like we’re talking about here, although eventually they will be.)

should also try to involve a third party (I'm thinking maybe Internet Archive?) to have signing span across institutions.

YES! This would be ideal. I think the whole idea of provable timestamps is most applicable when the use case is focused on accountability for a particularly contentious topic, and the best way to create social “proof” in this case is through the consensus of multiple disinterested parties.

b5 commented 5 years ago

Perfect. I'm hearing a desire to this, but let's do it right. In an ideal world we could provide a turnkey solution for a third party we'd be able to convince to help with proving timestamps. We can slot this as an RFC to be worked out