Hako is an app that empowers the user to control the access to their files. It uses IPFS to share encrypted data and NuCypher to secure access control.
In Depth article (including demo here) https://medium.com/@david.richard.holtz/hako-3825c3a033d7
Hako uses protocol called proxy re encryption to secure and permission data efficiently.
Unlike other file sharing services such as Dropbox and Google Drive, Hako does not place your keys in the hands of a large companies. The user is always in control of your keys and your data.
Centralized storage has a single point of failure (the company) and require a user to be online (connected to the central servers) in order to transfer data and delegate access.
Sustainable Concepts 👫Futari (Alice/Bob key combo identity) 🔗NUCID (smallest amount of data needed to share a IPFS CID and NuCypher policy)
Benefits ✅ Verified and built in data integrity (immutable data store) ✅Hako leverages Web 3.0 peer to peer protocols so users can directly share data, as well as access to a distributed network layer or a trusted federated re encryption network. ✅ Hako has no single point of failure and allow non-trusted 3rd parties to delegate access to data — while never being able to decipher the original message. ✅Built for ‘offline first’ file sharing. No need to connect to a network if running NuCypher locally. (half built while on an Airplane with no internet connectivity!)
Use cases 💡 Distributing large datasets 💡 Distributing data to many people 💡 IOT datastored (check out the original hearbeat example)
!!!!! IMPORTANT DEMO - KNOWN ISSUES !!!!! please read if using live demo 🐛Passwords must be 16 chars or more, this is enforced by NuCyphers keyring ( actual error: nucypher.config.keyring.NucypherKeyring.AuthenticationFailed: Password is too short, must be >= 16 chars.) - you will get stuck on the “Please wait while the Futari is being created” page 🐛Entering the wrong password will not throw any errors until you attempt to upload something (when you first use the password on the server) 🐛Decryption keys are not locked with a keyring on the server (so don’t upload anything important) 🐛Files that contain a “” in their name will fail because NUCID parsing is not intelligent and splits on all “”s ( so make sure there are no “_”s!) Also the NUCID expects to see a “nucid://” in the front of the link so don’t remove that. 🐛Hako is running on a federated network on the same machine as the server. This is to make sure no changes to the deployed network will break existing code. (So any policies granted in the dev net will not be available in Hako at the moment. 🐛Refreshing the page and logging in with another Futari will clear your file list. Files are only persisted if the same user is logged in as the previous user (for that browser). This is since all decrypted file data is stored in the browsers local memory. Supporting that your decrypted files are never shared outside of the local machine. 🐛Last known issue is that if a username has already been created the server can’t complete the key gen, and fails silently. You will get stuck on the “Please wait while the Futari is being created” page
Love your work David! Did you catch the Arweave workshop? I wonder when Arweave is a better fit than IPFS? In which user / product scenarios?
Great attention to detail. Really enjoyed the medium article and demo. Nice integration with IPFS.
Nice
Gut
This is super cool! Nice work
please check out - https://medium.com/@david.richard.holtz/hako-3825c3a033d7