Roadmap Wallet - Glow-Lang/glow GitHub Wiki

We want to integrate with existing software and hardware wallets to securely keep keys. (Future: or else provide a significantly better alternative).

A wallet is pointless if addresses are unintelligible gibberish that you can never be sure is quite right. Instead, we want to present identities in a human-intelligible way.

Scheduled

  • (2021-02) Design private vs public key rings schemas
  • (2021-02) Add CLI to add/remove/edit/tag public key information(?)
  • (2021-02) Add CLI to add/remove/generate/list/edit private keys (stored as secret data, identified by public address and/or public key identifier). Use clobber-file salt: #t to update the JSON file.
  • (2021-03) Identities as first-class UI-manipulatable objects. See #149[5d]
    • There is a Rolodex, “contact set” of known identities.
    • Some identities we control: we have known private keys (or we trust some other device we control to have access to them).
    • Identities have hierarchical subidentities.
  • (2021-03) All changes logged in a local monotonic journal. [3d]
    • Use an append-only journal to record all user-level changes and where they originate from.

Accounting

  • Keep a journal of all transactions
  • Always log the exchange rate of all assets into the user's unit(s) of accounting
  • Get exchange rate either from outside oracles or from transaction context itself
  • Be able to export the transaction journal to CSV
  • Be able to search or select parts of the transaction journal

Storage

  • Fully encrypt the private key file (see section below for decrypting)
  • Encrypt individual entries, not just the whole key file?
  • Once we have a good story to encrypt the private key file, also encrypt the "public" database (the one with less sensitive data).
    • NB: independently, we already recommend users should use full-disk encryption.
  • Make the change journal into a queryable database.

Interoperate with existing wallets

  • Prompt user for password at start of interactions
  • Use walletconnect protocols
  • Integrate with gpg-agent and/or ssh-agent
  • Support whatever linux desktop standards there are for wallets
  • Support whatever macos desktop standards there are for wallets
  • Support whatever windows desktop standards there are for wallets
  • Support whatever android mobile standards there are for wallets
  • Support whatever ios mobile standards there are for wallets
  • Support QubesOS-style isolation
  • Write an "app" for Ledger so we can safe manage transient keys
  • Write an "app" for Trezor so we can safe manage transient keys
  • Write more apps for smaller hardware wallets

Addressbook

  • Support sub-identity generation using Hierarchical Deterministic wallets:
  • Support CAIP-50 and such?
  • Backend to import and export (part) of the list of contact entries
    • Identify relevant standards?
    • What are the relevant opensource applications? Mozilla? GNOME? KDE?
    • What are the relevant proprietary applications? Google? Apple? Microsoft?
    • Maybe use JSContact ?
  • UI to import and export part of the contact list with other applications.
    • First-class contact sets as UI-manipulatable objects, not just “the” contact set.
    • Filter a contact set with tags / some query, plus manual selection.
    • Operations on a contact set: export, import, merge, etc.
    • Merge or split individual contacts
    • Import a contact set as an object, filter it, edit it, then merge the result into “the” contact list.
    • Ability to fix or normalize names not just in one context but all contexts.
  • Integration with whatever directories people use:
    • Handshake
    • ENS
    • OpenPGP
    • Keybase
    • Microsoft Active Directory
    • LDAP
    • SSL (?)
    • etc.?
  • Managing multi-signature contracts in terms of the identities that partake.

Reserving assets for a DApp

We want DApps to be able to complete interactions without users having to nurse every intermediate transaction to health. Indeed, in low-volume DApps, it is appropriate to request confirmation by the user at every step. But if there is a high volume of small interactions, asking for human confirmation at every step actually makes security worse by developing a habit in the operator to rubber stamp everything offered, thus defeating the purpose and opening the operator to attacks that hide a bad transaction in a sea of indistinguishable boring ones. Solution:

  • Have an interface to pre-authorize an application to sign transactions, as long as it only manipulates a given pool of assets.
  • "Virtual" solution whereby the authorization consists in handing the keys to the application, or to a somewhat more secure "wallet proxy" for it that enforces some accounting constraints, faithful tx UI, and dropping the key at the end.
  • (If on-chain fees are cheap) actually moving those assets so a sub-address in an HD wallet where the application may know that sub-address's private key.
  • Negotiating one of the above with some external wallet's API?
    • The wallet may either trust the client with a temporary key (root-key or sub-key depending on fee level), or
    • The wallet may give the DApp a token authorizing the DApp to have the wallet do the signing within those limits.
  • Internally, our own "wallet proxys" may implement the virtual safety approach handing out the UI a token approach, on top of a more barebones wallet API provided by the physical wallet.

Security domains

  • UI for managing tagged context
    • Every identity has tags, that determine in what contexts to use them.
    • Contexts are a list of tags or tag filters
    • Tags can themselves be hierarchical
    • Contexts can have background colors associated with them in the UI to make it clear.
    • Some interactions are only possible in certain contexts, i.e. you can only interact with a work contact from a work account, or from a personal contact from a personal account.
    • Having a set of active DApps that are valid in the current context
    • Only present currently valid results that fit the context’s tag criteria when searching for addresses (yours or others') or DApps.
      • Sort alphabetically, in historical use order, in most frequently-used order (with exponential decay?), etc.
      • Allow "advanced" or "cross-domain" search to explicitly select from multiple domains?
  • A special tag is "validity", that comes with a validity date and a reason, as in:
    • “Valid starting 2020-01-01 (joined the company)”
    • “Invalid starting 2021-12-31 (will leave the company)”
    • “Invalid since 2020-11-05 (person diseased)”
  • Isolation
    • Applications run in a context have limited capabilities that prevent them from accessing things outside their context.
    • Once deployed, a contract interaction happens in the narrowest necessary context.
    • Have per-DApp validation of parameters and also economic validation of what kind of parameters make sense
    • Support QubesOS
  • Runtime reflection mechanism so that cross-zone copy/pastes may have to be validated TWICE: once to authorize their leaving their origin zone, ones to authorize their making way into the destination zone.