2018-02-22 Engineering Meeting

Community Meetings
#1

Date/Time: 2018-02-22 @ 14:00 UTC / 09:00 EST / 22:00 HKT
Length: 45 minutes
Meeting link: https://zoom.us/j/416493133

Agenda

Please reply to this forum post with items you would like included on the agenda.

Each item should include:

Item name
Background information: Links to github issues, forum posts, etc with background information on the item
Desired outcome: what decision or deliverable would you like from the discussion of this topic at the meeting?
We’ll save ~10 minutes or so for community questions or comments at the end of the meeting.

I’ll turn proposed items into an agenda prior to the the meeting.

#2

I propose the following topic:

Clear distinction between regtest mode and mainnet in the Browser

Right now the blockstack browser doesn’t seem to really recognize to which network it is connected which leads to some weird behaviour such as:

  • Even though I use blockstack browser in firefox’s incognito mode, a new tab opens in the browser’s usual mode using the mainnet’s identity
  • Having registered an ID in regtest mode and changing back to the mainnet just leaves me with that ID
  • Something like a log out feature would be great to ensure clear separation between networks
  • The connection. between regtest mode an gaia is unclear, I only get 403 errors when an app tries to connect to storage in regtest

Aaron already posted some thoughts on that here: Setting up Developer Environments

While the MacOS browser supplies a development and regtest mode it is not really clear in which cases I have to use them. In my case I want to use a regtest core instance on a remote server while from my understanding the browser would start a local instance? I would appreaciate a more straightforward implementation for developers.

Greets
Martin

#3

Two topics I’d like to propose:

Data signing in blockstack.js

@jude started an issue to track this here:

This would be pretty great to have, and not require a ton of effort (we already have all the signing and verification libraries included, and code exists). However, something to think about here is the interaction with multiplayer storage. Namely, should Bob be able to verify Alice’s signed data? The answer is almost certainly yes. This involves two steps:

  1. Actual signature verification — that’s easy enough, the data will need to have the signing public key alongside it.

  2. Ensure that the public key matches the expected public key

How do we get the expected public key though? The address is the “last part” of the multiplayer storage URL, however, codifying that as a standard is another question.

Deploying a Transaction Broadcaster

The transaction broadcaster code is out there and works pretty well, we should spin up a broadcaster, thoughts? :slight_smile:

#4

2018-02-22 Engineering Meeting

Attendees

  • Ken
  • Aaron
  • Jack
  • Muneeb
  • Chase
  • Jude
  • xor
  • Shankarganesh PJ

Clear distinction between regtest mode and mainnet in the Browser

  • We should show the user’s testnet owner address
  • Also a bar to indicate that it’s in testnet
  • Gaia currently doesn’t have a testnet or development mode
  • Spawn development Gaia Hub in the regtest docker container
  • Will need a file driver

Blockstack.js Data Signing

  • Gaia currently either encrypts and signs data or stores it as unsigned plain-text
  • Need an option to sign data but not encrypt
  • Issue is how this interacts with multiplayer storage
  • Options are to add public key hash in apps object or parse it from the Gaia hub URL
  • Add a key in multiplayer getFile options to verify signature and throw exception if data is not signed
  • Will flesh out corner cases offline

Deploying Transaction Broadcaster

  • Jack will sync with Aaron to spin up a transaction broadcaster service on google cloud
  • Transaction broadcaster should be easily deployable by users locally, could be bundled with browser download
  • Users of the browser web app will have to use the Blockstack hosted broadcaster
3 Likes