I'm surprised it took me this long to invest time into understanding ots. Thanks for the motivation! I created a GH issue for it: https://github.com/stackernews/stacker.news/issues/206. Should be pretty straightforward to add. UX could just be a little ots logo next to Items with upgraded timestamps.
In this centralized context where practically everything is trusted, trusting SN to keep and not forge time is probably a relatively small concern, but it would be fun and also relieving to chip away at the trust monolith.
Note that upgrading timestamps is optional. The calendars will make the data available indefinitely, and third parties can back it up, so it's reasonable to just store the incomplete ones in your databases.
The way I'd implement it is to timestamp the content after the edit window has closed. Also, ideal would be for the SHA256 hash of what you're replying too also be part of the timestamped content, so there's a complete record of the context. Don't forget to hash content like inline photos too.
Opentimestamps is GREAT! I use it to timestamp git commits and legal documents (sign, scan, timestamp). Incredibly useful utility. Planning on building some other proof of existence tools on top of it and a simple asset tracking db.
I tried running my own calendar server once but had some trouble. Don’t remember what the issue was. Ended up donating some sats to the Alice calendar server and then moving on to something else.
Yeah, running your own calendar server isn't very helpful right now. We've got four of them, and that's plenty; each additional one means there's more data that the world needs to save to be sure we can validate every timestamp.
On the other hand, it's very helpful if lots of people know how to run a calendar server, in case the centralized ones go down and the community needs to create new ones. So feel free to experiment with running one! But better off that no-one uses it in production.
Yeah, that’s my thinking. The public calendar servers work great, but from a resilience perspective, I want to know that I can, so whatever software or processes I have that depends on ots can survive beyond the operations of those public servers :-)
Peter I follow you and I Star the project. I need time to analyze it deeply. I can understand this project is like a time stamp over blockchain to be inmutable. That can be so useful to garantice any process.
Your content gets hashed. That hash goes into a big merkle tree. The root of that merkle tree goes into a bitcoin tx. So you can prove in the future that a piece of content existed as of that bitcoin block. Super handy primitive
Maybe never? Taproot just saves a little bit of money, and makes proofs a little bit smaller, at the cost of increasing the chance of the calendars losing money to hard drive failures. The cost/space savings vs op_return are too small to care about.
Hi Peter, great to see you here! We need more people like you in this community.
Welcome, Peter.
Well, no better motivation to learn about OpenTimestamps than Peter Todd joining SN.
Ha!
yalls.org used to (still?) timestamped posts for precedence proof. It'd be cool and somewhat useful if SN did the same.
Proof this is me: https://twitter.com/peterktodd/status/1580945480082939904
I will grok it this weekend and give it a shot
Great to hear!
What language is the stacker.news backend written in?
Javascript
I don't know anything about javascript. But this should work for you:
https://github.com/opentimestamps/javascript-opentimestamps
I'm surprised it took me this long to invest time into understanding ots. Thanks for the motivation! I created a GH issue for it: https://github.com/stackernews/stacker.news/issues/206. Should be pretty straightforward to add. UX could just be a little ots logo next to Items with upgraded timestamps.
In this centralized context where practically everything is trusted, trusting SN to keep and not forge time is probably a relatively small concern, but it would be fun and also relieving to chip away at the trust monolith.
I'll try to get it done.
Nice!
Note that upgrading timestamps is optional. The calendars will make the data available indefinitely, and third parties can back it up, so it's reasonable to just store the incomplete ones in your databases.
The way I'd implement it is to timestamp the content after the edit window has closed. Also, ideal would be for the SHA256 hash of what you're replying too also be part of the timestamped content, so there's a complete record of the context. Don't forget to hash content like inline photos too.
Great recs. I’ll update the issue.
welcome to SN!
I used it when I was downloading the binary from lnd. I did not get the full idea but it made sense.
Good to hear!
There's also git support in OpenTimestamps that allows you to validate timestamps on signed git commits: https://petertodd.org/2016/opentimestamps-git-integration
Timestamps aren't some magic "this is valid" proof. But they are useful for limiting the scope of when an attack might have happened.
Welcome and enjoy the ride. Looking forward to reading more of your posts.
Opentimestamps is GREAT! I use it to timestamp git commits and legal documents (sign, scan, timestamp). Incredibly useful utility. Planning on building some other proof of existence tools on top of it and a simple asset tracking db.
I tried running my own calendar server once but had some trouble. Don’t remember what the issue was. Ended up donating some sats to the Alice calendar server and then moving on to something else.
Thanks for the donation!
Yeah, running your own calendar server isn't very helpful right now. We've got four of them, and that's plenty; each additional one means there's more data that the world needs to save to be sure we can validate every timestamp.
On the other hand, it's very helpful if lots of people know how to run a calendar server, in case the centralized ones go down and the community needs to create new ones. So feel free to experiment with running one! But better off that no-one uses it in production.
Yeah, that’s my thinking. The public calendar servers work great, but from a resilience perspective, I want to know that I can, so whatever software or processes I have that depends on ots can survive beyond the operations of those public servers :-)
Opentimestamps is a great idea
Peter I follow you and I Star the project. I need time to analyze it deeply. I can understand this project is like a time stamp over blockchain to be inmutable. That can be so useful to garantice any process.
Your content gets hashed. That hash goes into a big merkle tree. The root of that merkle tree goes into a bitcoin tx. So you can prove in the future that a piece of content existed as of that bitcoin block. Super handy primitive
Wen Taproot support in OTS?
Maybe never? Taproot just saves a little bit of money, and makes proofs a little bit smaller, at the cost of increasing the chance of the calendars losing money to hard drive failures. The cost/space savings vs op_return are too small to care about.
Very cool project! It would be nice if there was an API where you could send the hase to. So that it become easier to use different script languages.
I use it to copywrite my ownership of my strawman. Few know this shit, but is important if you want to be a sovereign man.