Scenario 2 - Stolen Device

We didn't go to deep into this yet, suffice to say that I think its a similar scenario to 1, but we different action needs to be taken in terms of the interface to ensure the custodians behave correctly.

Scenario 3 - Coconut Death 4 Realz

• How do the shard holders know who each-other are?
• They all know about a root message id. Each shard holder can do a shout out of SHA2(root).
• Another shard holder can look around and assume that anyone who also shouts out a matching SHA2(root) has another piece of the puzzle, because they knew the root. Are there missing assumptions here? Can this be cheated? Sure someone can just copy that SHA hash and paste it into a message, thus fooling anyone else who is looking for that string.
• Any other ideas?

Summary
Much of my thoughts around this today are really UX related.

The Dark Crystal interface really needs to separate user-flows and its narrative based on the differing scenarios / recovery strategies. For example, suppose rather than the simple case where peg's laptop gets smashed up by a falling cococnut, instead a giant walking cococnut robbed peg of his laptop (sorry peg!) and his identity with it. Supposing also that Peg has backed up both his Bitcoin private key and his SSB private key using that identity. When he comes to want to recover, the options to 'Return a Shard' and 'Forward a Shard' should not be in the same view. They could be easily mixed up and could result in a dramatic failure - rather than forwarding the old private key to the new SSB identity, peg's custodian sends the shard of the bitcoin private key back to the Coconut Robber. If a quorum of other shard holders makes the same mistake, then the bitcoin private key is revealed to the Robber.

The Dark Crystal interface doesn't at the moment allow a person to return a shard unless requested. But if the coconut robber has requested the bitcoin key shard back, it could easily be confused for forwarding the SSB key shard to a different identity. The interface really has to get a proper handle on this.

There's nothing about the interface at the moment that indicates precisely which shard the custodian should return. There needs to be somekind of metadata to indicate whether the identity is their SSB private key at the very least (which in effect acts as a master key to regain access to the other secret shards).

Conclusion

A scenario-based user-path as the interface is the better path. For example:

Dark Crystal app loads up and asks what what course of action you want to take.

1. Create a New Dark Crystal, Shard your secret and share it with some friends
2. A friend's lost their key? Send a secret shard back to its original owner
3. A friend's lost their SSB identity or had their laptop stolen? Forward a secret shard to another identity

With pictures animating the process and text explanation we can ensure that people know exactly what they're doing and which is the correct option / scenario to choose. Lets treat this as an opportunity to teach people about how it works and narrate that through imagery. We can do the same on initial sync when scuttling after having joined a pub. Much like how Ubuntu or Windows shows pictures when you're installing the OS. Dark Crystal can show a series of images explaining the different scenarios. Much like how MyEtherWallet warns about security and how to use the wallet when you land on their homepage.

Observations for Development

• Encrypt the gossip.json file with your ssb private key before sharding. Attach as a blob to the dark-crystal/shard message. Forward the gossip.json file when shard is returned to new identity. Once all shards are received, decrypt the gossip.json, inject into the incoming new .ssb folder with the new / old secret file, and switch identities. Wait for resync.
• We might want a new record (or could perhaps use invite-reply messages) called dark-crystal/forward that looks something like this:

{ 
  key: "%...",
  value: {
    content: {
      type: "dark-crystal/forward",
      root: "%...",
      shard: "*=.box", // encrypt the shard sent back using the destination identity's public key (much like the same pattern we've already used)
      gossip: "&...", // blobId of gossip.json file
    }
  }
}

• Write a flumeview-reduce that listens for dark-crystal/forward messages. When one arrives, query for other dark-crystal/forward messages that have arrived, and using them attempt to reveal the secret. If the secret reveals successfully (we've essentially calculated the quorum), append to the reducer a record that contains a list of the IDs of the dark-crystal/forward messages, and the quorum required to reassemble. In the front-end, we have have a pull-stream setup which will check this reducer and allow the secret to be revealed if the relevant information is available to reveal. This could also expose a set of actions to perform:
  1. Delete current identity and rebuild original identity
  2. Backup current identity and rebuild original identity

I hope this makes some sense, its a cut and paste job with some linking paragraphs from the last 2 days notes

In unrelated news... it turns out there's an Irish Porter called 'Death By Coconut'. I think the #mmt team should celebrate on the delivery of resolving the coconut death scenario this with a 4-pack each.