n2p5
commented
4 years ago Solid question! First, this was is built as an experiment, so take that for what it is. But architecturally, I chose IPFS + ETH because the state of the data is kept outside of the direct control of the contract owner. This is important because the “publisher” is only tasked to live as long as a checkin hasn’t occurred, and if the killcord key is released, it lives on the blockchain and in IPFS as long as both of those systems are running, which is probably longer than your pi could be running at home.
For a thought experiment, let’s think of being an attacker:
- a DOS or DDOS of your raspbery pi or even a cluster of raspberry pis is relatively vulnerable vs that of IPFS or ETH network as a whole. Again this was an experiment in playing with the idea of a public disclosure, if you wanted to use the killcord pattern for private disclosure, running this behind a VPN or mixnet has real advantages. But that is another conversation.
- I wanted to break out the responsibilities. with IPFS for storage and ETH for killcord state, the other interactions are the owner for checkins (this requires auth creds + volition) and the publisher, which can be hidden from the public. You could actually run as many publishers as you wanted and these can be hidden form the public entirely, run behind a VPN, run behind a mixnet, it doesn’t matter, the more, the safer. So contract state and the payload should be “radically public” while the owner’s volition (the ability to checkin) and the publisher should be hidden. That is the game I wanted to play here.
- If the owner vanished, the publisher engages with the final state change to ETH and that final output then lives as long as ETH + IPFS exists. This helps fight some sort of coordinated effort to kill all of your raspberry pis, since taking the state down would require engaging with “disinterested parties of ETH + IPFS).
- If all of the publishers vanished and the owner vanished before the final state change occurred, you would be out of luck. Keeping the publishers hidden and highly available is still crucially important.
I hope this helps with my reasoning. It also brings up an important point: it doesn’t have to be built this way and this tool is SUPER limited in its actual usefulness. I’ve put a lot of thought into a “next version” of killcord and I might start working on this in early 2020.
I’d like to explore:
- generalizing payload storage so you can choose other systems like tahoe-lafs, cloud blob storage (s3, etc), etc
- generalizing the contract API to support other smart contracts generally but also support private REST servers.
- changing the disclosure pattern to support “private disclosures”, I’ve put a lot of thought into this, which would add this idea of an “audience”, this version defaulting to “public” audience, but that you could use multiple audiences as a pattern and either disclose the key to decrypt the payload to that audience or even combine it with something like Shamir Secret Sharing so that you disclose a shard to 3-5 audiences and at least 3 have to combine their shards (cooperate) to generate the decryption key for the payload, etc.
ok - stopping here. This is probably way more than you bargained for when asking this question. Hope this helps!
If this application requires a separate server to be run in perpetuity, why is Ethereum or IPFS needed at all?
"It leverages a publisher tool meant to run autonomously on a trusted system or set of systems"
This makes me think a blockchain is not necessary? Why not just run a Raspberry Pi at home, and check in on that single device daily?