2019-01-03 Meeting notes: wallet dApp

Date

Jan 18, 2019

Participants

  • @Kelly Foster

  • @Ovidiu Deac

  • @Ed Eykholt

  • @Dan Connolly

  • @Lucius Meredith

  • @Chris Boscolo

Goals

  • How to best support users viewing Rev Send and Receive history via a command line wallet

Discussion topics

Item

Notes

Item

Notes

Ed’s post from Discord on Dec. 24

@odeac: and I had a good discussion just now. Looks like the mechanism for a wallet dApp to get the history of a user's Rev sends and receives might be best implemented with a new Account contract abstraction that stores its own history. The existing BasicWallet and Purse contracts and other block/DAG mechanisms obscure that type of audit trail (which could be considered a feature). However, for the adoption of RChain, a user must be able to see their conventionally transacted Rev Send and Receive history from a co-op provided dApp (e.g. a command-line wallet). WalletCheck will likely need some enhancements. I'm hoping that @odeac: or others will arrange a meeting for himself and some subset of @dckc: @kayvan: @kellyfoster: @Ned: @Kent: and me later this week to discuss how some of the requirements will be implemented.

User stories proposed for Mercury

https://github.com/rchain/rchain/blob/dev/docs/features.md

Dan and Ed ideas for command line wallet

https://docs.google.com/spreadsheets/d/1uN5hk6q008HpeEBoBq70OoEmYC5N4ybcajFb-_CmP6o/edit#gid=80188525

Related Jira issues

 

Higher abstraction of a wallet

  • Don’t give purse and wallet to users,

    • Challenge is it is difficult for users and creates risks creating contracts that add complexity where it’s not needed

  •  

Rholang challenges

  • Contract for wallet is not so difficult

  • Ovidiu discussed with Kent

  • What is difficult is preparing the Rholang infrastructure and test and debug the contract

    • NEED ability to test and debug Rholang outside of the VM

  • IDEA a wallet could be encapsulated in a single contract

Naming conventions for wallets

  • Concern the RChain wallet is not aligned to the industry. It will confuse users

  • Recommendation for nomenclature

    • Change how we've used “wallet” to date

    • Definitions

      • wallet = Client app for interacting with funds

      • account = Contract storing REV, public interface for storage of funds

      • purse = implementation detail and not visible to users of an account. Risk of losing traceability of funds.

  • design an account and an account contract

Open questions

  • How important is it to leverage ETH style for signing transactions (Dan)

    • Idea for an approach - Could we fork My Ether Wallet or Metamask to support this?

  • How to address mulitsig?

    • Is it in the same account contract or is it something else (ex Locker)

      • What is a Locker? (Dan)

  • How from a client perspective do we predict the unforgeable name?

  • What platform does the coop-provided wallet app run on?

    • Suggestion make it similar to RNode operation

Action items

@Kelly Foster try to schedule meeting for Sat, Jan . 5 re: open questions

Decisions