@Nikolai "For example, if the UI waits until everyone has agreed to join the cabal, and the cabal exists as an entity, only then is each prompted to enter their secret, therefore secret doesn't need to be stored anywhere and is never revealed."

@Kieran "Aye @Nikolai so this is what I was getting at above, where if you get the members to agree to being a cabal, then ask for the secret, no storage is required. I think this is the best solution. "

TL;DR

If we are building a BMW (Better Multisig Wallet) from the ground up, and a cabal is already existing - then we have an opportunity to make the multisig wallet and do the sharded backups all in one-ish step.

Is this direct to MVP? Not sure?

MVP use cases

We settled on:

1. SSB identity (individual's secret backed up among trusted friends, one-to-many)
2. Multi-sig wallet (everyone in the group wants to mutually back up each other's keys, many-to-many)

Examples of why (1) may be needed can be seen in Index of #DeprecatedSSBAccounts where we see some of the foremost "experts" in the network having this need (including me, twice). An example of (2) would be the instantiation of a collective multsig wallet. You can see more of our explorations of these steps here:

MMT: Let's create a bitcoin multisig wallet (async)

Review of Ceremonial Invokation of BTC Multisig Wallet

As mentioned in the TL;DR comment above, I think the steps that @Alanna has outlined above are a very solid first jump in the right direction. IMO, it can be simplified within the context of a collective multisig wallet where the cabal already exists.