You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 6, 2020. It is now read-only.
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
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:
how much we should prioritize building this? Is this vital to use cases like EDGI's, or should we stay focused on basics like exporting clean spreadsheets & come back to this after?
If we sketched out a clear roadmap to land this feature, would anyone be interested in taking it on?
should also try to involve a third party (I'm thinking maybe Internet Archive?) to have signing span across institutions.
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.
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
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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 onqri 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?
The text was updated successfully, but these errors were encountered: