2017-12-15 Engineering Meeting

Community Meetings
#1

Agenda:

  • Review planned architecture
  • Review locations of current state
  • Discuss guidelines
  • Discuss locations of state

Attendees:

Larry S
Aaron B
Daniel H
Ryan S
Ken L
Gina A
Daniel H
Daniel M
Nick N

Review planned architecture

From: https://github.com/blockstack/blockstack/issues/376#issuecomment-350149957

33742984-e91966cc-db78-11e7-93d6-558c22ac3b99.jpg2224×1526 287 KB

Current state

Adapted from: Duplication of Code & State in Blockstack

Blockstack Browser

  • Encrypted 12 word keychain phrase
  • Next unused address index
  • gaia hub configuration information
  • URLs of providers such as UTXO provider, search provider, etc

Blockstack Core/CLI

  • Wallet information
  • Selected storage providers
  • Storage provider access tokens
  • URLs of providers such as UTXO provider, search provider, and other data in the directory containing client.ini

Profile/token/key file

  • Profile
  • App public keys (Future?)
  • Device public keys (Future?)

localStorage of apps using Blockstack.js

  • Gaia hub configuration info
  • Transit private key
  • User data

Guidelines

Proposed: (Let’s discuss/add/remove)

  • Stateless whenever possible
  • Minimize settings that need to be stored
  • Minimize information end users need to remember
  • Principle of least astonishment
  • Let apps manage their own state
  • Secrets should stay secret
  • Privacy by default
  • More?

Issues Discussed

  1. Restoring a user’s view of Blockstack
  2. State that’s recoverable from blockchain
  3. Gaia hub discovery
  4. Browser state
  5. Keychain storage
  6. Blockstackd configuration state
  7. Gaia hub configuration state

Restoring a user’s view of Blockstack

  • 12 word phrase → generates addresses
  • Addresses → allow us to find zonefiles
  • Zonefile allows us to read the user’s profile/keyfile
  • Profile/keyfile specifies gaia hub
    • Note: shouldn’t necessarily be the same for all identities, but our software will probably only support one gaia hub URL for the time being

State that’s recoverable from blockchain + atlas

  • Addresses / names — we should use HD wallet style derivation of addresses, where it adds addresses up to some gap (probably a gap of 0), and users manually add more
  • Zonefile allows us to read the user’s profile
    • Ryan pointed out that the profile should be backed-up in this case — if the gaia hub denies you access to your profile, you should be able to supply a back-up that you can restore from

Gaia Hub Discovery

  1. URL to profile.json is linked from the zone file
  2. profile.json contains Gaia Hub write URL

Solutions to Browser State

  • Gaia hub URL is not browser state — it should be written in the user’s profile
  • Other browser state for now is device-specific
    • For now, it’s all defaults anyways, so we shouldn’t necessarily worry about syncing it
    • In the future, we’d want to sync it using gaia storage, however, it can’t use a normal app-key, because that app-key will be userID and app specific, so we can do something like derive a specific path off of the master xpub
  • For browser settings that should be synchronized between different kinds of applications, we should have OS-specific synchronization methods
    • Q: how does the browser communicate with those?

Keychain State

  1. Private keys should be stored in OS specific keychains
  2. This will allow the CLI and browser both to access this

blockstackd State

  1. There is no user state in blockstackd
  2. There is configuration data for the particular node — this is similar to configuring any other server, goes in an .ini file

Gaia Hub State

  • There is no user state in the Gaia hub configuration (except, in the case of a user-operated hub)
  • The configuration data for the particular node lives in a config.json file
    • We should either use an ini file here, or switch blockstackd to using a json file
7 Likes