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

To compartmentalise this chat and to avoid a mega-thread am forking this from: %XjDAorB...

@peg:

@mix suggested we do some well thought out design before changing anything on the front end. Very good idea.

@kieran suggested we do some async brainstorming before doing synchronous planning.

So im going to describe the absolute minimum, simplest (and not very well thought out) interface i can think of - and encourage others to point out the problems or enhancements.

For each shard on the 'Others shards' tab there is a button 'Forward shard'. Clicking on it opens a modal which displays a warning (which can for sure explain more than in the drawing) and allows the user to choose a recipient, which must be someone they are following to reduce the probability to choosing the wrong person. The 'forward' message is published.

A security enhancement could be to hide the 'forward shard' buttons until a special button in the corner called something like 'Emergency features' is clicked, to discourage their use.

A nice-to-have would be a mechanism for automatically importing your SSB keys when creating a 'new' dark crystal.

#mmt #darkcrystal #dark-crystal

The bit i'm more unsure about, in terms of the language being confusing, is from the perspective of someone who has received 'forwarded' shards:

I sat down with a blank slate and thought about this and have come up with something which is a mirror of @peg's suggestion. I have a bunch of other feelings about stuff the Others Shards section is missing - but we might as well leave that till we do a full round of participant testing and interface improvements. For completeness here are the things my brain threw at me:

• (1) a filter so that we can see others shards reduced to a specific person
• (2) emergency button to enable to forward button as peg suggested.
• where a shard has been returned, the date that it was returned.
• the version of the shard type (TMI?)

I am not sure if this all came up in the initial thread but I had thoughts about - how do we know which shards to return.

Say Robyn has sent me 10 shards, how do I know which of them to return? I wouldn't presumably - shards do have a date attribute, but it is unlikely that Robyn would remember the date that they made their SSB back up ritual. Would it be more memorable if the system created a long seed and showed this to Robyn at the time of ritual and then sent along to the shardholders. I am not sure there is alot of benefit to that route for the additional bytes it would cost.

A simpler mechanism would be for me to return to Robyn all the shards that I am holding of theirs.

As such we'd need a Forward All <Person>'s shards

@peg @kieran had you thought about this in your journies? I have read through the initial write up but didn't see either of you mention this (though I may have glossed over).

This is an image of the interface for someone wanting to recover their identity. When they arrive to the /dark-crystal interface they see an existing option in My Crystals called "RECOVER SSB IDENTITY". They'll need to click into this to make their requests, or it is where invites they have made OUT OF BAND will go to.

This is the view when clicking into "RECOVER SSB IDENTITY".

This place serves three purposes.

One is the container to collect forwarded shards. These can be grouped by Ritual Date

Another purpose is for you to be able to message and request all shards from particular people IN BAND.

The third and super important purpose is to give the person a script they can use with their friends. It tells them super easy their CURRENT SSB identity so that others can more easily know they are sending the shard to the right account.

cc: @mix @kieran-two

@mix and I spoke and mix's quick write up superceeds my suggestion of using dates as a grouping mechanism (as we can use rootId)

mix: "combinations" and "permutations" are ways of calculating how many different ways there are of doing a thing.
e.g. for pick 4 shards out of 15 and try to combine them (whether the order doesn't matter) the calculations is :

n! / ( k! * (n - k)! ) = 15! / ( 4! * 11! ) = 1356

anyway, we don't need to do this because all the shards have a root attached to them, so as long as that's in the forward message (which the schemas you made say it is) then we don't need to guess which shards go with which.... so it's just a matter of using all the shards you have then checking some MAC to see if you had a quorum

A quick bookmark to say that mix and I spoke and mix highlighted an even more minimal path along The Way. If he doesn't get to it by tomorrow then I'll write up my perception of it.

Also had the great idea that we should figure out quick handle/aliases for the different specific scenarios within Coconut Death.

@peg "this is a great idea and perfect for the 'theft' case."

Sweet! I'm tending to agree with @mix that we focus on the theft case for minimal coconut

@peg "but i have mixed feelings about using it for 'swim'."

I'd love to hear your raw mixed feelings. I feel like there is something in this pattern - but have yet to full submerge in it ...

Hey all,

So in my previous post Falling Coconuts I really wanted to emphasise an approach to the UI which takes a scenario based / narrative based approach.

The Dark Crystal interface really needs to separate user-flows and its narrative based on the differing scenarios / recovery strategies.... 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...

So here's some thoughts on what the interface could look like. I've added scenario-pathways for swim / theft and the forward action.

Home View

Home view specifies 6 different user-choice pathways through the application.

1. Create a new Dark Crystal
2. Return a friend's shard
3. Recombine shards to recover a secret

These three views already exist in our prototype application. Pathway 2 aligns with the 'Others Shards' section. Pathway 3 aligns with the exiting Dark Crystal Show view.

1. Recover a lost of stolen identity - swim / theft
2. Forward a shard to a new identity
3. Commune with your peers to recover a Dark Crystal - inheritance

Recover View

This is much like Dan's view above, but I've added the capacity to request someone to forward a shard to you. This means when you've gotten reconnected to the network via a pub, you will be able to see your shard holders and message them directly with a request that they can respond to with a dark-crystal/forward message (maybe a nice to have at this stage). Or you can copy your new identity string and send it to them via a different communications platform. The positive of having a request system again is it takes the weight off the custodian of having to type in a @public_key_.ed25519 (and possibly making a mistake). It means a request can be send, then you can message someone out-of-band saying 'Yo, that was me', they can confirm with you via a secure means and then its super easy for them to forward...

Forward View

So here we've got two potential pathways.

1. See forward requests
2. Select a shard to forward

Both will end with the same warnings!

The forward requests area allows a custodian to cross-reference requests from an new identity with shards from an old identity and select the one they want (which one to choose is likely going to have to be worked out out-of-band as we're not publishing any shard metadata at the moment).

The select a shard to forward area allows you to choose against your list of friends OR input an identity string.

I haven't done a view for scenario 6 - Commune with your peers to recover a Dark Crystal - inheritance (coconut death 4 realz). There's a bit more involved in this and possible other pathways within it.

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.

I've realised I've totally missed off a section for the Recovery View. There's two possibly pathways here, much like the Forward path. There's the one I have specified, which is beginning a new recovery process, and theres existing recovery processes, i.e. you've begun the process of recovering already, and you need a place to draw together all the forward messages you receive and act accordingly. For example, it could be that once you've hit quorum for forward messages, you get the option to back-up your current .ssb/secret, and then writes a new .ssb/secret with the returned key (and a gossip.json if available), reboot the application and watch it sync with the old recovered identity.

Or for example you could declare your old identity 'untrustworthy', and get the people who forwarded you your old shard to concur that you were the new real you. The rest of the community (and the other shard holders for your previous identity) could then choose to recognise the actions of this group of people declaring that the new me is in fact me, and the old me is the Coconut Robber.

@Eb4890 you might be interested, as this ties into what you were chatting about a trust declaration system for git-ssb.

Here's a vision of pathways 1 - 5, this time on a whiteboard (it made me really sad I couldn't find my coloured markers...)

@dan

I have proposed here an alternate strategy where we return ALL shards of a person

This might be a possibility, though it could then expose all those secrets rather than just the one you need, which I think is kinda counter-intuitive. For example, in the case of ssb account recovery, you don't want to expose all your other secrets, just the ssb one, otherwise all the others are then available... And the SSB one would be available anyway (in .ssb/secret), whereas the others might normally be protected in a password manager or some other mechanism?

Sorry my last post is addressing swim case. Theft it would make total sense. I've added checkboxes in my UI diagrams to allow for returning multiple!

@kieran that is stellar work :)

Aside: You have given me a total brainwave for our logo / visualisations. I'll do some work and then come back to you :)

@kieran have yet to deep dive into your flows - but on first pass I am getting a "Choose Your Own Adventure" vibe. I like it.

this is where reality is bumping up into the realms of your Dark Crystal-esque Dugeons and Dragons module @hailey!

OH GAWD

I just looked at the actual choose your own advneture there... I don't like it!!! here is a better one instead :)

Yeah man that first one you posted is pretty bleak!

@dan having thought more about this, for this DC sprint, I think the Forward All is going to be the right approach for theft.

@kieran I did see this. It's hard to talk to the parts because it's in a big diagram. I like some of the flows and interfaces, and others I would do differently.

hey @kieran @peg @dan hassan can I please request when you make mockups that you spend a couple of minutes making them a little easier to access visually? I've found some of these quite hard to follow because of the denisty of the flows, but also because of the quality of the images.

Here's what I do with GIMP. You can do fancier things but this takes me about 30 seconds :

• (optional) crop
• Colors > Auto > White Balance
• (optional) Image > Scale Image ... > set width down to 1200px

Here's some more useable excerpts that I'm about to add to the trello board:

@mix these were made first on paper then I re-drew them on a board at the end of the day in a window before the OTF call so was somewhat in haste. I don't think they're unreadable though (that said, its my own handwriting...) and I had a narrow timeframe in which to complete it.

I'm going to redraw them again today with more care on individual paper sheets.

I really feel strongly that we should think seriously about a UI based on pathways (much like the choose your own adventure map, with less doom). I'm worried that this is going to be overlooked without any real discussion.

Forking conversation to here... %fFAQ35y...

the ability to read them was a different point than whether these are included @kieran. I think the original drawings were fine, my main feedback was a careful photograph + a minimal edit would make it way easier to read.

off to read fork now