@peg : "you've lost me a bit on your example with ssb-grants and mobile-ssb quests. For sure having inter-dependent backups between the two groups would help them support each other in case of loosing a key. But how does this help them collaborate with funding for a project with shared goals? Isn't the key recovery process only for 'emergencies'? "

Ignore me for now. I'm talking about 10 steps ahead which isn't super useful right now, other than to say - coordination amongst more complex groups/orgs can be aided with privacy respecting auditing. This was one of the takeaways from the 3 year EU funded research project called DCENT. I will try to dig up some of the research which highlights complex cooperative trading networks and how flows of information about internals of an org can help with things like writing mutual-credit. I should emphasise this is not about trustlessness but rather it is about de-risking relationships so that there isn't undue pressure put ON trust relationships, which can strain the trust... rather trust can be put into trusted governance, reporting and auditing proceedures - which can free up the humans to foster , hold and nurture the human-communication-relationship stuff which can't be "systematised".

peg: "Are you imagining some sort of automated propagation of shards which become shards of shards? Or even shards of shard shards mixed with someone else's shardshard. So maybe youre carrying shardshardshardshards for people you dont even know?

That sounds amazing! But mind bending! I think its gonna take me several days to figure out what exactly the implications of that would be..."

Yes, we're talking degrees of automation but with OPT-IN moments during the flow. TBH I am not sure I have ever seen anything like this in computing systems before. It might be a new thing (just using old tools, it's just that our computing patterns now afford new utilisations e.g. agent-centric append only logs allow automated shard distribution).

A.K.A Decentralised Password (secret) Recovery

At least on paper it seems possible to design this into protocol in the way that it's almost impossible to lose your secrets.

peg "Im trying to understand what sharing shards over ssb could help do that wouldn't be possible by some other secure communication channel, (eg: encrypted email or some mobile app)."

This is an example of "OUT OF BAND". You use signal, or pgp email to share your shards. This means there needs to be somewhere where you create a map to where these secrets live so that if you disappear the parties who need the secret can discover the secrets. e.g. if you leave one with you partner, then we of mmt would need to discover how to contact your partner.

An "IN BAND" approach, which is what we are looking at with SSB means that it would be possible to contact people, under certain conditions (which we could design), to recover secrets. This reduces the work that needs to happen to recover secrets.

In past systems this type of thing has be SUPER DIFFICULT due to the question of IDENTITY. e.g. if you disappear and your partner is contacted by phone by me - how does she know I am who I say I am? This is just one example. SSB also goes some way to solving the identity question and edge cases as IDENTITY is contextual within the community of people within SSB. Like Keybase, your partner could see the private message I am requesting a secret from is the account which your account has friended and has had many conversations with, etc etc etc

Run out of steam - keep asking the clarifying questions peg!