# Wallet session outline

### A. General information
| | |
| -------- | -------- |
| Session title | Wallet ring |
| Facilitator | [ligi](https://ligi.de) |
| Scribe | taratan |
| Time and date | 11:00 - 12:30, 29.10.2018. |
| Number of participants | *42* |

### E. Notes

#### Topics Brainstorm
* Wallet distribution: e,g, how do we get less reliant on google and apple here. Discuss alternatives to them like f-droid. Also think about the future - decentralized distribution systems anyone? Reproducible builds?
* Wallet reputation staking on standards? E.g. we agreed last year at DevCon3 on EIP681 and a lot of wallets did not yet implement it - which causes a lot of trouble. So one idea would be that projects could stake reputation on standards and it gets slashed when they do not implement it in the agreed timeframe. This reputation could then be used in the decentralized distribution systems mentioned above.
* Storage of private keys (currently extremely excited about the status.im [hardware wallet](https://github.com/walleth/khardwarewallet) ) **
* WalletConnect - how to push it forward and get more adoption (on wallet and application side) - Versioning/Upgrade paths/backward compatibility **
* How to decentralize more (light client incentive layer like VipNode, ultra light clients, minimal verification clients like INCUBED) - other ideas? Classification
* mETHadata
* making wallets accessible on low end devices (e.g. nokia one) for the emerging world. Also how to make wallets work in bad network conditions **
* Wallet (interoperability) comparison matrix **
* User data and disclosures
* Wallets that interact with native dApps (vs web apps)
* Design system/language for wallets/dApps
* Off-chain payments
* Representing ether in different denominations

#### Storage of private keys (currently extremely excited about the status.im [hardware wallet](https://github.com/walleth/khardwarewallet) )

* Hardware Wallet cards
* could substitue the horrible UX when using mnemonics
* for transfering value between users
* for onboarding (preloaded with ether/tokens/..)
* hardware wallet for ~5DAI (without display) - in volume really cheap (big volume could even go to 1DAI)
* HTC devices coming with in-built wallet
* not going to work with iOS
* needs special NFC capability (https://github.com/status-im/hardware-wallet/issues/6)
* is more of a feature than a bug as it discurrages people from using a closed system
* the card signs, doesn't expose your private key in *this* process
* There are cards with e-ink display on it ($20DAI before markup) Nexus (??)
* Graphics hardware -- security?
* Are people going to use smart cards or use their devices

* Why move away from mnemonic phases?
* With the card you don't need the mnemonic phrase?
* No, you just do a backup with the card

* UX experience
* Smart card reader plugged into browser//mist

#### WalletConnect
* Wallet connect is an open source standard for a secure interaction between moble and desktop
* In the future maybe mobile to mobile
* 99% of dapps use metamask easy to use
* wanted to open up more dapps to the mobile wallet
* what kind of patterns do we want to introduce to wallets
* private keys from device to device: to dapps and to wallets

* Connect using a relay server
* currently building into libp2p for pubsub functions
* relay servers and libp2p not that different, libp2p provides unified API for transports
*
* Deep-linking
* standardization for iOS and android
* choosing connections to different wallets
* What information does the user convey with wallet connect?
* currently metamask injects your account(?) into every website you visit
* in 2 days, they will deploy EIP?? to disclose the connection approval and requests from website
* second feature: every JSON RPC requests -- sent tx, signed
* wallet subscribes to dApp session
* doesn't automatically sign your tx (similar flow to metamask)
* propose a new type of interaction
* initiate a kind of "game" session, authorize the wallet to sign the tx within a session
* project Peft(sp?) be able to give some permits to the wallet (say, not more than 1 ether at one time)
* L2 wallet: set certain amounts ??, tradeoffs that need to be decided
* Automatically signed transactions
* Not a good behavior
* Can we create a transient private key?
* that has an authorization contract
* Better pattern that asking say, metamask to always approve this transaction
* ephemeral key sessions/UX
* authorize this key for certain amount of time of spend amount
* that proceeds within application or domain-specific
* may be good to formalize what these policies look like
* should be able to revoke sessions any time

#### Wallet reputation
* topic more about blockchain governance
* using kickback concept/staking for EIPs

#### mETHadata

* https://github.com/ethereum-lists/mETHadata
* after mycrypto and mew split, metadata for tokens: e.g name, twitter account
* trezor is compiling into the app (the old version: https://github.com/ethereum-lists/tokens)
* after last secureth, we had a discussion to expand this beyond tokens
* this address is an address from x exchange
* for instance, this one has hacked, or has audits
* transaction metadata
* between from and a to
* call functions to smart contracts
* data payload has to be in a hash format
* eth registry: smart contract information for wallets
* wallet goes onchain and verifies source code (inspection) and verify that this contract is asking me x request
* metamask has a list of already known transactions -- limited list
* a lot of people have inecntives to verify sc on ether scan, but what metamask does is to translate those with a lot of transactions
* possible solution?
* marketplace of curators to verify this, to run source code through API
* just source code verification, not audit
* metadata: includes logo, ticker, decimal
* mycrypto or etherscandb have their own registries
* trying to bundle these
* these wallets are duplicating each other's work for the registries
* cross-verifications between wallets
* solving two prblems: parsing data block and third-party verification stamp of reputation
* eth registry, trusted source onchain curated by wallets
* Keep a blacklist on chain?
* seems similar to TCR
* a lot of people trust etherscan as source of truth
* data silo
* four byte (sp?) as alternative?
* may not be legal to just scrap etherscan if you look at terms of contract
* Secureth, companies interested in signed commit hash

#### Things we agreed on
* Our mission shall be from now on "Make wallets more useful, interoperable, user friendly, private, decentralized, safe and accessible."
* For scaling reasons we will form sub rings (Mobile, Desktop, Hardware)
* Outer rings still exists - just augmented by inner rings for specific discussions around one of this sub-topics