Schema scheming

I'd argue that the shard record itself should contain no information about what is required to restore the secret (or if it does, its a choice made by the creator of the shards, hence forth to be referred to as @Grace or @95WQAJ1...)

Agreement

@Grace should retain the information about quorum / number of shards in a record called an agreement. From @Grace's perspective, the agreement and the shards are created at the same click of a button. First we shard the secret, then hash each shard and store them on an agreement record, which also details the quorum and the number of pieces in total, and then we create n secret records, each containing a shard, sent to each recipient.

{
  "key": "%rBpGhzSwvhToQJU7cTJfK+qQlMqT//GmLMaAQi0xGKc=.sha256",
  "value": {
    "previous": "...",
    "author": "@95WQAJ1XZju4YFpLib3JYdbx//BCtr5dq3bR9jPxYWs=.ed25519",
    "sequence": "...",
    "timestamp": "...",
    "hash": "sha256",
    "content": {
      "type": "agreement",
      "quorum": 2,
      "shards": 5,
      "recps": ["@95WQAJ1XZju4YFpLib3JYdbx//BCtr5dq3bR9jPxYWs=.ed25519"],
      "hashes": [
        "5feceb66ffc86f38d952786c6d696c79c2dbc239dd4e91b46729d73a27fb57e9",
        "6b86b273ff34fce19d6b804eff5a3f5747ada4eaa22f1d49c01e52ddb7875b4b",
        "d4735e3a265e16eee03f59718b9b5d03019c07d8b6c51f90da3a666eec13ab35",
        "4e07408562bedb8b60ce05c1decfe3ad16b72230967de01f640b7e4729b49fce",
        "4b227777d4dd1fc61c6f884f48641d02b4d121d3fd328cb08b5531fcacdabf8a"
      ]
    }
  }
}

In this case, recps only includes self (private message to self), so people receiving secret shard are unaware of everyone involved, to include more, just add to recps. @Grace can choose to make everyone in the group hidden of visible to the others, or just make it so only one other person knows, or just themselves.

Secret

Received by @Elvis or @ArWnnLH...

{
  "key": "...",
  "value": {
    "previous": "...",
    "author": "@95WQAJ1XZju4YFpLib3JYdbx//BCtr5dq3bR9jPxYWs=.ed25519",
    "sequence": "...",
    "timestamp": "...",
    "hash": "sha256",
    "content": {
      "type": "secret",
      "root": "%rBpGhzSwvhToQJU7cTJfK+qQlMqT//GmLMaAQi0xGKc=.sha256", //  root is the agreement record
      "secret": "80171f51d1f9cf6f6a8f3b08dee2ca5575cec57f32d02ed9f4435e940f1888637e1005e43232048fee13dd8804628",
      "recps": ["@ArWnnLHUb7GTLs4HcBPdNUyCjxTCDUwV92OmuOPaqj8=.ed25519"]
    }
  }
}

Announcement

The agreement and all the secrets being sent triggers a public announcement stating that Grace has socially secured a key. This tells the community that Grace is looking out for their security and is a reliable person to entrust a secret to. The more keys secured by your network, the higher the trust. This is super simplistic, but you get the idea.

Issues:

• How can this be validated? Whats to stop me just building a bunch of fake records and making it look like I'm reliable?

Recovery

Lets talk about different methods for identity verification.

Personally I think the functionality for @Elvis to return the shard to @Grace should be there, along with a bundle of warnings telling people to check 'out-of-band' that they are in-fact still in possession of their SSB identity and are the person they claim to be (a phone call / physical meetup). Then its pretty simple, a request / invite can be sent by @Grace, and a reply can be sent containing the shard by @Elvis.

For SSB identity recovery, it'd be interesting to talk about tying two identities together based on community validation. i.e. if @Elvis and @Annabelle and @Derek all agree that @Grace's new identity is in-fact @Grace (once again, out-of-band), then the old identity can be matched up with the new one once recovered. @mix does the recent tick-tack feature allow this?

Issues:

• @Grace may not remember the exact configuration of how to put the shards back together, and that information is encrypted with their old key pair.

As @peg noted in out last workshop, and in his schemas post above, a hash of each shard could be kept by @Grace, to validate a received shard sent back by someone. That way it helps work out exactly who sent the broken shard. Rather than the reassembly algorithm just not working.