Dark Crystal Web3 is a proposal sourced from an initial blog post by Vitalik Buterin in ___, that Magma Collective is currently working on developing into an MVP. It’s a social recovery protocol for which we identified three main important affordances: The app doesn’t require the recovery partner to remember anything except the access information for their main ethereum wallet. The app should be secret-agnostic, meaning it can backup any kind of secret, including but not limited to an ethereum private key. The app should allow for both the anonymity of the secret owner AND the recovery partners. Because the app is handling secrets, and perhaps secrets with a high value, validating the security assumptions and requirements for trust in our project was crucial to examine.

As part of our initial phase of MVP development, we undertook comprehensive user research with core tools and protocols in the Web3 and Ethereum communities, conducting interviews with representatives of WalletConnect, 3Box, Metamask, Gnosis Safe, Rainbow and Tally as well as circulating an anonymous survey on Twitter and Discord. What we learned was endlessly fascinating, and summarized here for the benefit of the community.

Besides the significant confirmation that usability should be prioritized, and a number of proposals for what that might include, perhaps the most significant finding is that the cold storage user is rare. Cold storage refers to storing a key in a way that it is never connected to the internet – this could include a paper wallet, or a hard drive that is only connected to offline computers. It’s widely considered the most secure way to store a secret key. However, transacting with a cold storage key presents significant usability hurdles: usually a wallet program must be downloaded and built on an offline computer, which packages and signs the transaction, which is then transferred to and broadcast from another device. Since our app was handling secrets, we wanted to know how likely this kind of process would be for our users?

Perhaps surprisingly, the cold storage user is rare. Or more accurately, the overlapping subset between keys in cold storage and keys users would back up with our app is very small. In all our synchronous conversations, we heard that though it was important to support the cold storage pathway, but this person would not use it themselves. From interviewees who did have a cold storage key, we heard that they would use a system like ours, but only for their smaller-value hot wallet keys. Survey respondents were somewhat more favorable to cold storage – with 33% saying they would require their key to stay in cold storage at all times. With a longer research timeline, it would be useful to discuss with this user segment further, and discover how they differ from our interviewees. We also received feedback that the most security conscious users likely had their own backup systems, and would be unlikely to trust ours, and that instead the person who needed social recovery the most was non-technical: “Anyone who can use a command line doesn’t need social recovery.”

Indeed, what kind of technical literacy we could require from the user was another area of discussion – what tools, wallets, etc are familiar or required by our potential users? Architecturally speaking, Dark Crystal Web3 involves a hosted browser-based dapp, and a rust command-line component with a frontend that can be run locally. The considerations that led to this architecture plan were wrapped up the desire to support cold storage. Both our survey respondents and interviewees were very technical, with 80% saying they would be comfortable using a command line application if necessary. We did hear some reluctance though, and we suspect that if a fully hosted version of our app was available, only the smaller subset of significantly motivated cold storage users would pursue using it otherwise. The feedback was so strong that, though we’ve worked from cold-storage to hosted in terms of design and execution, it’s worth considering that it perhaps should be the opposite. Though we have targeted and mostly discussed a browser-based dapp as the main point of entry, we received strong feedback from 2 of 6 interviewees that a downloadable app was a more trustworthy and preferable design pattern, due to the frequency of phishing attacks. Overwhelmingly tools like Metamask, Walletconnect, mobile wallets, and block explorers presented no problems for interviewees or survey respondents. Though we have attempted to keep the protocol agnostic to what kind of secret is being backed up, we believe all of our potential users are fully onboarded Ethereum users. We heard explicitly many times that a user who is not already an Ethereum user would be unlikely to choose an our social recovery protocol.

• All in-person calls confirmed that our typical user would have a “main ethereum address” that they would be unlikely to forget under any circumstances. Interestingly however, 3 of 5 survey respondents said it was possible or certain that the user had forgotten this, or never had one

• The requirement that it’s important to remove anything the recovery partner must remember was significantly validate
• We received criticism in two cases for storing the encrypted secret onchain, one coming from the perspective of cost primarily, and one coming from concern over the quantum threat to cryptography
• Feedback was very favourable for anonymity, but we heard repeatedly that once a significant threshold of users were part of the app, the “needle in a haystack” version of anonymity would be sufficient in many cases. How to bootstrap until this period is reached is not clear
•
• 100% of survey respondents believed the some set of secret shards would be leaked by insecure out-of-band transfer from the recovery partner to secret owner, our in-person calls echoed this belief strongly, but did agree that it could likely be descoped from mvp
• maintenance – what happens in the future? How to test that the secret is revoerable? Time delay for recovery. Ability to switch recovery partners

>[name=peg] maybe we can fit this graph in somewhere to break up the text:
>

> [name=peg] also i think it would be good to mention some of the developer-y discussion we had. as in the interviews, we weren't just getting opinions from possible users but from wallet developers.
> in particular, that people would like to see a standard/protocol for encrypted wallet-to-wallet messaging. as thats something that came up a couple of times and would make a massive difference to us trying to build this recovery system.