So I started putting our more concrete ideas as cards on trello, and this got me thinking what exactly we will need to do. and its made me a bit concerned with our model.

Thanks for digging in @peg :)

Without knowing what the quorum is, our test for having enough forwarded shards returned to recover the secret relies on identifying the secret somehow. This means we will be able to recover SSB keys, since we can look for a string ending in .ed25519 or a parsable bit of JSON containing one.

With you so far. I think.

I'd say in the first case we're going for the most simple. Alice has backed up her ssb key with a group of people and she can remember who those people were for that secret and she can also remember the quorum.

But, just to be safe she rings all of the people involved in the coven and chats with them and gets them to send all shards which she has ever sent them.

Luckily we have computers to help us, so there will be alot of combinations of shards, but not anything which a computer will find too taxing with the number of people involved and the number of shards involved.

Is that the scenario you are thinking of peg?

But we will only be able to recover secrets which we can identify somehow. If someone wants to recover a secret other than their SSB key, they would either have to tell dark crystal what they think the quorum was, or sift through failed attempts at recombining. If the quorum was 5, they would need to check 4 potential secrets. Which wouldn't be so bad, but it would make the interface a bit ugly and confusing.

Hmmm. Couldn't we absorb some of the mess behind the interface as we attempt recombines till something works.

And again - I'd suggest in the happy path we leave some of this complexity to the human as a first step.

I think it's ok for us to assume that people will remember the shape and appearance of the secret that they have dumped into the crystal.

You might say - well that's no problem, recover your SSB key and then use your old identity to recover your other secrets. But what if (a) you didn't backup your SSB key. or (b) your SSB identity was compromised and you definitely do not want to use it to recover your secrets.

I think in this first case we are designing for (a). It is good to look ahead though to make sure we don't paint ourselves into a corner.

This does open to another common suite of thangs - which is that Alice will now have two identities. What should we do about that in the Happy Path sense?

I know that some other implementations of shamirs secret sharing get around this problem by appending the secret with it's hash or a checksum before sharding. In fact you could use anything, a few bytes of zeros, or the word 'scuttlebutt' UTF-8 encoded.

hash or checksum is good.

I know that this will make the shards even bigger and we are already struggling to fit them into an SSB message. and I know this would be a breaking change and mean bumping the schema version number. But i have the feeling we will thank ourselves later for doing this sooner rather than later.

agreed it is better to make breaking changes sooner rather than later. i'd also say this is an excellent opportunity to try out the version pattern, which has not been tested yet. and good to do it when the stakes are lower. I'd even go so far as to advocate for this as we want to surface these types of issues sooner rather than later.

I'm willing to say - ok, lets not worry about this now, and go for MVP for SSB identity recovery. But i think this is really something we'll want to address before the next major 'release'. Unless anyone can think of an easier way around this problem?

I think what you have written makes sense.

@dan hassan was there any mention of this in the SLIP39 specs? At first glance it does not look like there is, but i've not had a deep dive.

I've not had a deep dive yet.

ps. this is about identifying the original secret not about verifying individual shards. Which is another problem...

I can't recall the exact solution to this, but I had thought that we solve this for "free" as a side effect of ssb append logs... I could be wrong though.