I'm not trying to derail your work @mix but I proposed a set of design approaches that were based around the point made in above post several times and each time the thrust of my point was overlooked. I made this point in my first post several weeks ago and have made it in each post subsequently. I don't think your design at the moment takes this into account, and if it does or you intend it to, then talk to me about it, because that is where my interests lie.

See backlinks where I made this point:

Falling Coconuts

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.

Interface for 'forwarding shards' / ssb identity recovery for dark crystal

So I feel like taking this kind of approach is important because it separates return shard completely from forward shard and makes it quite easy to understand what course of action is the right course of action. Also by streching it out into multiple views, it gives more space for warnings and information. Having it all compacted into a single view feels a bit dicey and doesn't leave much room for info notes or other helpful messages on how to use the app correctly.

UI Pathways

So I feel like taking this kind of approach is important because it separates return shard completely from forward shard and makes it quite easy to understand what course of action is the right course of action. Also by streching it out into multiple views, it gives more space for warnings and information. Having it all compacted into a single view feels a bit dicey and doesn't leave much room for info notes or other helpful messages on how to use the app correctly.