# Metamask research

###### tags: `dc-web3`

### Goals for this call:

- user research, but about you specifically as a user, but also relaying your sense about your own users and the ecosystem in general
- feedback about any pitfalls, tradeoffs or weaknesses about this approach we may not be seeing
- discuss integration options

### Description of what we’re building

A social recovery app with two major roles: secret owner and a recover partner. 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.

##### Our users:
- Secret owner is fairly technical, able to run a rust cli app locally, has different kinds of wallets, familiarity with burners and mixers.
- Recovery partner has a main ethereum wallet that they continue using and unlikely to lose access to.
- Both users are familiar with trustworthy encrypted messsengers/email services

##### Architechturally:
Three main code bases, a hosted dapp where recovery partners can connect with popular wallets, a smart contract, and a rust client used by secret owners that has a _______ (locally-served browser interface?) and can be run on an airgapped machine

##### Recovery partner first steps:
- connect metamask to our dapp
- are prompted to sign a standard phrase signature(standard_phrase)
- our dapp uses the signature as the seed for a new public key public_key_seed(signature(standard_phrase))
- recovery partner sends this public key to the secret owner

##### Secret owner steps:
- collects all the pub keys from partners
- generate the shares using local rust app and encrypts them to each pub key
- local rust app generates a ____ payment request of the encrypted shares packaged for our smart contract
- secret owner uses burner key and mobile wallet to send transaction

##### Recovery steps:
- recovery partner gets either 1) secret owner address OR 2) secret phrase
- recovery partner connects to dapp and regenerates signature
- recover partner uses public key and 1) secret owner address OR 2) secret phrase to recover encrypted share
- recovery partner decrypts share(s)
- recovery partner transmits decrypted share(s) to secret owner

### Questions:

* How likely would you be to use a system like this?
- 6/10
- to secure access to my hot wallet, not cold storage
* What would be your biggest concern about using a system like this?
- user-experience - how easy is it to recover my secret and how much time does it take - so usability for the recovery partner
* Are there any additional features or security guarantees not yet discussed that would be important to you?
- the ability of the recovery partner to not have an ethereum address
- envisioning a pulse-checking mechanism embedded in the system - that warns the partners to check on someone if e.g. some activity has not happened in some period of time
- dead-man's switch - some providers are working on an implementation of this - strongly believe that this would be of great interest to a lot of people, to know that if something happens to them, that their funds will not be locked forever
* Would cost be a concern when using an app like this? If so, how much would you be willing to pay in transaction fees?
- maybe i would have some concerns about transaction fees on ethereum; on e.g. polygon it would be fine
* What tools and apps would you want to use to interact ie. do you have a mobile wallet that can scan a payment request? Beside ofc metamask, are there any other wallets our dapp component must support in your opinion
- i imagine that i should install a mobile application that will give me access to a dashboard and show me who i'm protecting, who is protecting me, what is the current status of my social recovery, how many times have i requested to recover my key - a mobile application installed from the app store would be preferable to a browser-based app, because it has less potential for phishing attacks
* How many recovery partners would you choose, and with what threshold (minimum number for recovery)
- 6/10 - more than 50% of partners as threshold, e.g. 3/5, 10 ppl gives more distribution, more decentralisation

### Feature rankings:

How would you rate the importance of these features? (From 1: unimportant to 5: essential)

* Recovery partners stay anonymous - 3
* Secret owner stays anonymous (we think this would require them sending transactions from a burner wallet, which had been funded with eth that had been through a mixer) - more important for secret-owner to stay anonymous...so 3
* Secret that is backed up is able to be anything (pgp private key OR ethereum private key OR arbitrary message) - 1
* Secret owner can generate and encrypt shares on an airgapped computer (secret can stay in cold storage) - from usability perspective, not good - 2
* Secret owner can back up more than one secret with our tools
* Secret owner can back up more than one secret with our tools AND use the same set of recovery partners - dilutes value proposition of the product - you already have a specific target audience, better to focus on the niche

### Scenarios:

How likely do you think these recovery scenarios are? (From 1: impossible to 5: certain)

* Secret owner can remember the address the transactions to our smart contract were published with (even if a burner account) - 1
* Secret owner has forgotten their main ethereum address - 5
* Secret owner doesn’t have a main ethereum address - 2
* Secret owner used an arbitrary string as their “lookup key” and has forgotten it - 4
* Secret owner loses computer AND forgets their main ethereum address AND the address the transactions were sent to the smart contract with (burner) but remembers who the recovery partner are - 5
* Secret owner forgets who the recovery partners are
* Secret owner dies, recovery partners know who each other are - yes you should be able to recover - but one part needs to be invisible from all of them, but could be given verbally to someone - in the case of automatic recovery there needs to be one extra layer of security - e.g. catfish example, where one extra trusted person has an additional piece of (offchain) information that is necessary for the recovery in the absense of the secret owner - so that in the case that the recovery partners collude, they cannot recover the funds - this person would in any case be a beneficiary, so that they do not have a motive for collusion, as it is essentially their own funds
* Secret owner dies, recovery partners do not know who each other are - 5
* Recovery partner loses access to their main ethereum account - 5
* Recovery partner uses an insecure service to send the recovered share back to the secret owner - 3

### Metamask specific questions:

1. Support for EIP-681?
2. Wallet to wallet messaging?

### Initial questions and comments on our description:
- what is the value proposition over e.g. argent wallet?
- anonymity of secret owner and recovery partners
- wallet agnostic & secret agnostic
- critique of the friction required to use e.g. my father as a recovery partner, as partner currently needs to have a wallet address/be on-chain
- solution needs to maximise user-experience
- should also be chain-agnostic
- your solution has a market fit, but has an inclusion problem
- can i see a list of the addresses for which i am a guardian, and can i see a list of who is a guardian for me?
- re. anonymity as a feature - if i am adding social partners, i don't want them to be anonymous, i want to know who they are
- the anonymity layer is because we are using a smart contract as storage for these shares, so they is anonymity to the outside, who is interacting with the smart contract
- the additional steps for anonymity are not necessary - i have no problem for people to know my social partners