-
Notifications
You must be signed in to change notification settings - Fork 5
Quick Update
Participants:
- Andrew Koh
- Dazza Greenwood
Meeting Purpose:
This is a routine update/feedback session pertaining to development of open source blockchain digital signature code being developed by Andrew Koh as an MIT student worker on the Human Dynamics research group open source R&D/prototype project of Dazza Greenwood at the MIT Media Lab.
- Short walk through of current code with explanatory voice track.
- URL: https://www.youtube.com/watch?v=1h0EkD9UlgY&feature=youtu.be
I first started looking in to blockstack id to see if I could make use of their apis and utilize the key management/ signing tech to try and sign a piece of json. However, it turned out to be a really deep rabbit hole that was way to complicated to try and integerate in to a simple application. Next after talking with Christian for a bit I realized that ethereum core libraries does a lot of the key management and I could sign using web3js. However, after playing with it a little bit more it became apparent that it would be better to use bitcoin core libraries as it was much simpler and easy to use. After deciding on bitcoin-core I implemented some basic signing demonstrations, as well as, hashing some of the data to make signing more managable. Additionally, the hash provides a way to check if any of the data within the json was tampered with because we would never get the same hash on different contracts. I also got pdf hashing working, but later it turns out that it isn't actually possible to open files within the browser as a filestream, so a work around for that will need to be found. However, I came up with a reasonable schema for signing, and the demonstration for signing works
With my signing piece more or less resolved the primary challenge of the project was getting the client side app to make requests to the signing bitcoin rpc server. Originally, I thought it would be a small thing that would not take up too much time, but it really dragged on as I was trying to find a work around for Access-Control-Allow-Headers that prevented the client from ever receiving a direct reply without proper headers. I tried using the built in webpack server the react app came with initially to try and proxy all requests, but to no avail. Then I tried utilizing an express server that would independently host all of the react website materials while acting as middle ware to connect to the json rpc server, which also did not work. Then I played around with nginx to see if I could add the headers directly to the post requests made by the client to the server, but the problem became that even if I could I was not able to put the correct headers in the reply. So, our final work around that I figured out was using nginx in between the rpc server and the website hosting server as a way of proxying such that it seemed all traffic was coming through one port. This solution finally worked.
As mentioned before the client side app is not allowed to make changes to any of data on your computer. This presents a little bit of a challenge because now we would need server side api to manage the signed data, and the client would have to send back the signed object to update the rest of the app. I started looking in to this today, but in the mean time we at least have a way of returning the signed JSON object.
-
For Andrew: "Can you please provide a link (above in the update section) to a quick video walkthrough of the current code so I have something up to date for feedback and discussion?"
-
For Dazza "...can we figure out what the official format for things are going to be? because documents and claims have completely different formats which is weird but for now I'm just working around it also I pushed to signing code for documents"
-
For Andrew: "How can we update the code so verification does not depend on file location"