Re: Blockchain Technologies Feature Analysis

On 10/07/2016 10:08 PM, Melvin Carvalho wrote:
> Are the terms in this attachment a basis for a vocabulary?

Yes, and we've started working on a vocab here:

http://web-payments.github.io/flex-ledger/vocabulary.html

This is the vocab that's used for the proof of concept ledger we've
implemented here:

http://dhs2016ledger.digitalbazaar.com/

If you open up a JS debug console, you can see what's sent to and from
the Ledger HTTP API. We'll be documenting the HTTP API over the next
several weeks. You can see a high-level view of it here:

http://dhs2016ledger.digitalbazaar.com/docs#_ledgers

> I'm very reluctant to criticize the work in any way, because I am 
> basically in awe of it.

But there is so much to criticize! :)

It's very rough and early, but we wanted to circulate it to make sure we
get feedback early... especially if we're wrong about something. We
cover a lot of ground in the analysis, so plenty of space to have messed
something up along the way. :P

We're going to be working on furthering this work at Rebooting Web of
Trust and have submitted a topic paper to dig in deeper there:

https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2016/blob/master/topics-and-advance-readings/fit-for-purpose-blockchains.md

> But I think different users will have different takes on which types 
> of URIs to use, which I think is under the flexibility of the spec, 
> but not always conferred in the examples.
> 
> e.g. urn:sha256:7fa3b9eaa8d92d2b87abf83d88a92ff23
> 
> Could this be an ni: URI?

Yes, of course. :) It could potentially be any URI and I think it would
be a mistake for us to pick just one.

> Similarly there seems to be a wide mixing of HTTP document URIs, HTTP
> data (fragid) URIs (lack thereof!), and content addressable strings.
> e.g. design choice here will have different levels of protocol
> coupling, and decentralization features.

Yes, what's in the spec is a rough first cut. Over time we'll try to do
a better job of explaining that the range of options are far greater
than what's in the spec right now.

> I think programmers building systems with this spec are going to
> have to have to do a lot of trial and error (as I have been for a
> few years) or somehow get some insights into the trade offs on using 
> different URIs in each part of the data structures.

Agreed, which is where we hope this community comes in. We only have so
many spare cycles. We can document what we do, but we need others to vet
whether or not these data structures and vocabularies work for them as well.

> Hopefully over time this will become more apparent, and feed back 
> into the specs, or complimentary material.

+1

> In any case, amazing work, what's next steps for this?

Over the next month we plan to:

1. Update the Flex Ledger specification with:
   * Details around the Ledger HTTP API
   * Updates to make it reflect the proof of concept we built for DHS
     http://dhs2016ledger.digitalbazaar.com/
2. Further identify areas for standardization at RWoT

https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2016/blob/master/topics-and-advance-readings/fit-for-purpose-blockchains.md
3. Do some work on Blockchain extensions for Linked Data Signatures:

https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2016/blob/master/topics-and-advance-readings/blockchain-extensions-for-linked-data-signatures.md

We'd love your input on any of that, Melvin. Same goes for the other
smart people in this group. :)

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Rebalancing How the Web is Built
http://manu.sporny.org/2016/rebalancing/

Received on Monday, 10 October 2016 00:24:36 UTC