HashDrop A zero-trust app for proving that you had a document at a specific time.
Summary
HashDrop lets you prove that you had a specific document at a specific time. This was a crypto project that had genuine utility. Since crypto was known for being unintuitive, I figured I would have a unique edge in writing an app that would be more intuitive than anything else out there.
I was inspired by this patio11 post:
https://www.kalzumeus.com/essays/dropping-hashes
In his case, he wanted to prove that he wrote something at or before a specific date, but he didn’t want to publish the actual document until sometime later. Security researchers will sometimes do this. They’ll hash a document describing some vulnerability, and then publish the document after the vulnerability is patched.
cb04b3ec5377cd7ac02c27b1e539a563dcdc984df0a37c543abb08b2bdc667fa84a32094a89be032a685c473bb381d6eebbc8482683331cbd8859209263da98a
— Patrick McKenzie (@patio11) March 25, 2020
Goals
There are two parts to this project. The first part was generating the hash. And the second was getting that onto the blockchain. I was able to get this working. The hard part was packaging this up into a user-friendly experience that was also secure.
Another goal was to have the entire app runnable locally, or copyable onto your local IPFS node. This would let the you ensure that the app was not modified. You’d be able to verify your own copy of the app (in principle), and continue to use it as long as you’d like.
Finally, I wanted to let the user create private drops. Since files were already stored on IPFS, a public network, I needed a way to ensure that the user could create private drafts. This was a little tricky because the entire point of the app is to be zero-trust. I didn’t want to store any data in a centralized manner.
Solution
I was able to get the app to encrypt and/or hash documents, and publish the hashes onto the blockchain, retrieve the files, and then decrypt them. I also generated unique URLs for each drop that could be shared on sites like Twitter:
https://hashdrop.me/#/drop/bafkreihia2rjdt6d4ypyhomngrhok7r6rez4ztwoj62f4feb6h2wbzyowe
Learnings
I was a little too ambitious about what I wanted to accomplish. There were many yaks worth shaving. Should I have leaned on making the site easy to newcomers to use? This was a monumental task in itself. This meant putting in copius amounts of error handling logic around ensuring that the user has MetaMask installed, is on the right network, has a balance, etc. And because gas fees randomly spike, would it be worth pulling this data? What can I expect the user to know about IPFS?
Some highlights:
- Storing all the user data on IPFS either meant forcing the user to make frequent saves, which increased the gas cost for the user, or trying to get clever about storing user data locally in a secure way.
- It was going to have to be a hybrid app eventually—a standard database-backed site as well as a decentralized system for storing the critical stuff.
- The IPFS Chrome browser companion had some means of storing the app locally, but the feature wasn’t ready enough for me to use.
- I ran into several bugs with the crypto libraries I used. I wrote about my woes here.
- I tried various L2s. Many were in various stages of development. Conveniently, they were generally interchagable. At the time of building, it wasn’t obvious which one would become the most dominant. I suspected Arbitrum or Optimism might eventually win out, but they were’t ready yet.