Re: Blockchain Standardization (was Re: PR for playground)

On 3 April 2017 at 12:15, Mountie Lee <mountie@paygate.net> wrote:

> personally I think turtle (https://www.w3.org/TR/turtle/) will cause
> confusing to represent ledger data.
> it has too much features than json.
> but also
> it has enough features to represent ledger data.
>

Turtle and JSON-LD are more or less the same thing.  There is a one to one
mapping.

Turtle is a bit more human readable tho.

It also has an excellent upgrade path for advanced users, through TriG
(already standardized) and n3 which bring AI-like intelligence to the
declarative layer.

But where turtle really shines is in the examples.  Almost all JSON example
I've found as a developer to be confusing and often containing subtle
errors or anti patterns.  Almost all examples I've seen in turtle are easy,
intuitive and in line with best practices.

JSON is simply a fashion of web 2.0 which is thinking in trees, rather
than, thinking in graphs.  I'm equally comfortable with both, but the true
power of the web is when every node is a first class citizen.


>
>
> On Mon, Apr 3, 2017 at 4:21 PM, Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>>
>>
>> On 3 April 2017 at 09:05, Mountie Lee <mountie@paygate.net> wrote:
>>
>>> one important thing CG will disagree is
>>> no central registry of identifiers (even for ledger types)
>>>
>>
>> URI's a little bit centralized but not alot
>>
>> Each URI scheme will be registered with IANA and have a spec describing
>> how you introspect on that URI
>>
>> Specifications are always a form of centralization, but if written well
>> they can allow enough flexibility to take into account everyone's use
>> cases, and even those not yet imagined.  This is where a good
>> standardization process can create rich and scalable eco systems.
>>
>>
>>>
>>> for the message format JSON (including JSON-LD) is adaptable.
>>> but for content of message, still not sure "how"
>>>
>>
>> At a high level the serialization doesnt matter too much as many are
>> interchangable.  What you are doing in the data is creating a large graph
>> at the data layer of the web / internet, much as the web of documents spans
>> many different domains and affinities.  A block chain is special in a sense
>> in that it is largely domain invarieant (private / shared block chains
>> being a special case).  The well-known pattern is a great way to make URLs
>> domain independent.  What I think we have missing is an 'overlay network'
>> which links together all the public block chains.
>>
>> So, simply you have items like a block header, the block, the merkel
>> tree.  These are all data structures taht sit in documents and are linked
>> to each other, much like one block header links to another.  The trick with
>> linked data is to name things with URIs to enable this scalability.  After
>> all, a block chain is simply a type of linked data, hence the "chain".
>>
>> Similarly if you are describing a user or account you will want to tie
>> key values to those accounts.  That will make up your data structure.
>> Whether you use JSON or Turtle is probably your choice, tho Im sure it will
>> raise the usual debate in spec writing (actually, it's not too important).
>> There's also neat technologies like Linked Data Notifications which allow
>> new blocks to propagate and grow the chain.  I'd personally recommend
>> Turtle over JSON here as pretty much every example I've ever seen in JSON
>> is just confusing.  Turtle is a simple language that's human and machine
>> readable that can be picked up in a few hours, and gives you are real feel
>> of how linked data should work -- however, I suspect I'll lose that debate,
>> in any case turtle I have found very instructional :)
>>
>>
>>>
>>>
>>>
>>> On Mon, Apr 3, 2017 at 3:42 PM, Melvin Carvalho <
>>> melvincarvalho@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On 3 April 2017 at 07:00, Mountie Lee <mountie@paygate.net> wrote:
>>>>
>>>>> at Web Payments WG had similar issue.
>>>>> and they published Payment Method Identifiers (
>>>>> https://www.w3.org/TR/payment-method-id/ )
>>>>>
>>>>
>>>> Thanks for the pointer.
>>>>
>>>> There's two types of decentralized identifiers.  One uses URIs to great
>>>> a giant network.  One is human readable, and should be mainly used for
>>>> display purposes or in (small) proprietary networks.  Web architecture 101
>>>> says to use URIs, and those are the ones that should be standardized.
>>>>
>>>> Politics can also play a role here, but we should aim to minimize that
>>>> in the blockchain CG via appropriate pushback, in order to create scalable
>>>> block chain technology which is sorely needed.
>>>>
>>>>
>>>>>
>>>>> Decentralized Identifiers can be formatted as URL style or email style
>>>>> for example
>>>>>
>>>>> https://my.ledger.com/public_bitcoin_ledger/address
>>>>>
>>>>
>>>> The de facto way to denote a document on the web.  Remember also that
>>>> documents contain data, just as files contain data.  This data can include
>>>> human readable or memorable identifiers too.
>>>>
>>>>
>>>>>
>>>>> or
>>>>>
>>>>> address@https://myledger.com/public_bitcoin_ledger
>>>>>
>>>>
>>>> -1 Not a URI.  Should not be used as part of the global graph.  It is
>>>> not robust, it does not scale, and looks like a bit of a mess.  This is
>>>> more appropriate for a silo or proprietary system.  Or for a human readable
>>>> shortcut.
>>>>
>>>>
>>>>>
>>>>> or
>>>>>
>>>>> address@public_bitcoin_ledger
>>>>>
>>>>
>>>> as above
>>>>
>>>>
>>>>>
>>>>> regards
>>>>> mountie
>>>>>
>>>>>
>>>>> On Mon, Apr 3, 2017 at 4:24 AM, Melvin Carvalho <
>>>>> melvincarvalho@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 2 April 2017 at 20:29, Adrian Hope-Bailie <adrian@hopebailie.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>> On 2 April 2017 at 04:19, Melvin Carvalho <melvincarvalho@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2 April 2017 at 04:19, Manu Sporny <msporny@digitalbazaar.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> bcc: Credentials CG
>>>>>>>>> cc: Blockchain CG
>>>>>>>>>
>>>>>>>>> Migrating this thread to the Blockchain CG mailing list as it's
>>>>>>>>> become
>>>>>>>>> more blockchain-y, than web payments-y or verifiable claim-y.
>>>>>>>>>
>>>>>>>>> For those that didn't see the start of this thread, it is here:
>>>>>>>>>
>>>>>>>>> https://lists.w3.org/Archives/Public/public-credentials/2017
>>>>>>>>> Mar/0023.html
>>>>>>>>>
>>>>>>>>> On 03/31/2017 11:25 PM, Adrian Hope-Bailie wrote:
>>>>>>>>>
>>>>>>>>>> I am interested to hear from those of you involved what the goals
>>>>>>>>>> of
>>>>>>>>>> these [Blockchain Standardization] initiatives are?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I think the goals are different between the standards bodies, and
>>>>>>>>> personally, I find it very difficult to track everything going on
>>>>>>>>> at the
>>>>>>>>> moment as things are still very dynamic.
>>>>>>>>>
>>>>>>>>
>>>>>>> So it's not just me!
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>> What are you trying to standardize?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I've heard at least these answers to that question:
>>>>>>>>>
>>>>>>>>> * governance for each blockchain
>>>>>>>>> * decentralized identifiers
>>>>>>>>>
>>>>>>>>
>>>>>>>> I think we have to standardize decentralized identifiers, as
>>>>>>>> everything else is built on that.
>>>>>>>>
>>>>>>>> +1
>>>>>>>
>>>>>>> I feel like a lot of the technical standardization work is riding
>>>>>>> the blockchain hype. It's big "S" standardization just for the sake of
>>>>>>> standards bodies not wanting to miss the boat.
>>>>>>>
>>>>>>> Somebody please tell me what an ISO technical committee is going to
>>>>>>> standardize wrt DLT and Blockchain. The ISO process is way too slow to be
>>>>>>> effective in such a fast developing area.
>>>>>>>
>>>>>>> IMO technical standardization it will be ineffective until it has a
>>>>>>> focused use case (like DIDs). Part of the reason Interledger has been
>>>>>>> successful is that it's not trying to standardize something broad like DLT
>>>>>>> it's focused on value transfer.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> We've been stuck on this topic for 10 years as everyone has their
>>>>>>>> pet favorite identity system.
>>>>>>>>
>>>>>>>> What is needed is a system that will interoperate, and we should
>>>>>>>> aggressively throw out identity systems on the criteria that cant be shown
>>>>>>>> to interoperate (which is most of them!) or have significant traction.
>>>>>>>>
>>>>>>>> The main problem I see is that people are fascinated by overloading
>>>>>>>> identifiers to do two (or three) different things.  This is wrong.
>>>>>>>> Identifiers should be opaque.  The reason being that different people will
>>>>>>>> overload in different ways, and that leads to failure to interoperate, and
>>>>>>>> balkanization.
>>>>>>>>
>>>>>>>
>>>>>>> Actually I think the problem is interoperability in the various
>>>>>>> protocols used to resolve and discover addresses and services from an
>>>>>>> identifier/name.
>>>>>>>
>>>>>>> And crucially, the need for identifiers to be useful and accessible
>>>>>>> to humans.
>>>>>>>
>>>>>>
>>>>>> Typically a human will never see their URI.  Inquisitive developer
>>>>>> types might dive into that, but not regular users.
>>>>>>
>>>>>> Tied to those URIs will be human readable labels, such as firstame
>>>>>> lastname (e.g. facebook) or email address (eg google), but neither of these
>>>>>> will be your unique URI, they will be artifacts of UI.  There is a trap
>>>>>> that is easy to fall into, which is to conflate the operation of the UI (ie
>>>>>> what a user types in), with the universal identifier used to create a
>>>>>> social graph.  This is a key limitation of web 2.0 systems such as OpenID.
>>>>>>
>>>>>> Each type of URI will have ability to lookup more information about a
>>>>>> user.  In HTTP this is well standardized with linked data.  Other systems
>>>>>> will need to popularize lookup systems, and grow a network effect around
>>>>>> that.  This is normally a lengthy process (years or decades).  HTTP URIs on
>>>>>> the other hand have the advantage of a large network, and well defined
>>>>>> lookup systems that are the most widely deployed on the planet.  So having
>>>>>> a good strategy for this kind of identifier will be critical.  That's not
>>>>>> to say that HTTP URIs are the only game in town, other types will gain
>>>>>> traction over time and they should all be able to play nicely together so
>>>>>> longs as specifications allow that to happen.
>>>>>>
>>>>>> I think for newer protocols it would be an advantage to standardize
>>>>>> ways to map them to HTTP URIs too.  This is sometimes done with the
>>>>>> "well-known" pattern.  One type I've been interested lately in, is ipfs
>>>>>> which seem to have a nice eco system for working with hashed content.
>>>>>>
>>>>>> Perhaps it's going to be possible to align ipfs and did identifiers
>>>>>> for the domain (decentralized) independent paradigm.  IPFS want to also
>>>>>> implement Linked Data so that could help interop.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> The most logical thing to do is to start by saying standardization
>>>>>>>> of identities MUST be URIs.
>>>>>>>>
>>>>>>>> Then look at ecosystems within each URI scheme:
>>>>>>>>
>>>>>>>> For example
>>>>>>>>
>>>>>>>> http URIs have a perfectly good spec that is widely deployed called
>>>>>>>> WebID.  Alternatives in the http world can be proposed, but let's be ready
>>>>>>>> to standardize what makes sense.  I would recommend labeling any identity
>>>>>>>> system that relies on http 303 redirects as an anti pattern, as experience
>>>>>>>> has shown they are a nightmare to deal with, and also they mix the data
>>>>>>>> layer with the transport layer.
>>>>>>>>
>>>>>>>> bitcoin seems to have significant traction as a uri scheme and fits
>>>>>>>> into the anyURI category
>>>>>>>>
>>>>>>>> I think enough work has been done on DID URIs to merit further
>>>>>>>> investigation
>>>>>>>>
>>>>>>>> Of course mailto: and tel: URI schemes exist.
>>>>>>>>
>>>>>>>
>>>>>>> This is a nice start but then there needs to be a standard discovery
>>>>>>> protocol per scheme.
>>>>>>>
>>>>>>
>>>>>> Yes.  Well, only if you're going to use that scheme.  If you use HTTP
>>>>>> URIs the problem goes away.  A better question might be why you would want
>>>>>> to use something else?
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> We have a standard encoding for a Universal Resource Identifier and
>>>>>>> this has an allowance for a scheme so that we can define a different
>>>>>>> Universal Resource Discovery Protocol per scheme.
>>>>>>>
>>>>>>> We have at least one already: HTTP
>>>>>>>
>>>>>>> Assuming you have this, the final piece is a standard representation
>>>>>>> of a resource. i.e. If you give me a URI that you say identifies a person
>>>>>>> then when I use the appropriate discovery protocol for that URI scheme I
>>>>>>> should get back a resource I know how to interpret.
>>>>>>>
>>>>>>> (We're changing topic here again)
>>>>>>>
>>>>>>
>>>>>> I dont think this is too far off topic.  The purpose of a URI is to
>>>>>> create connections in a network.  The natural next step is, tying key value
>>>>>> pairs to those URIs allow user facing technology to hide the complexity
>>>>>> from the user and create web scale systems.  The sanest way to represent
>>>>>> those key value pairs is the existing standard of Linked Data, choosing
>>>>>> your preferred serializations (from experience I highly recommend turtle
>>>>>> for advanced users).
>>>>>>
>>>>>> Another option would be to create a proprietary representation, and
>>>>>> try to popularize that through standardization.  I'd recommend against
>>>>>> going down this route, as Linked Data is starting to gain decent traction.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Perhaps we should start a wiki page on identity, and lay out the
>>>>>>>> guidelines to achieve standardization.  This is the building block for
>>>>>>>> everything we do.
>>>>>>>>
>>>>>>>>
>>>>>>>>> * interledger transactions
>>>>>>>>> * interledger linking
>>>>>>>>> * standardization around Bitcoin/Ethereum
>>>>>>>>> * smart contracts
>>>>>>>>> * blockchain data models
>>>>>>>>> * HTTP APIs
>>>>>>>>>
>>>>>>>>> So, there is technical standardization and political governance.
>>>>>>>>> Our
>>>>>>>>> organization is most interested in the technical standardization,
>>>>>>>>> but I
>>>>>>>>> struggle to see any initiative that has drawn more than a handful
>>>>>>>>> of
>>>>>>>>> blockchain organizations to the table. Interledger seems to be the
>>>>>>>>> most
>>>>>>>>> far along. I think we're making progress for cross-chain
>>>>>>>>> decentralized
>>>>>>>>> identifiers (DIDs). The Linked Data Decentralized Ledger stuff is
>>>>>>>>> new,
>>>>>>>>> but I'm speaking at a workshop on the topic day after tomorrow in
>>>>>>>>> Perth,
>>>>>>>>> Australia and will have a better idea on what the industry is
>>>>>>>>> thinking
>>>>>>>>> wrt. traction at that point (I don't expect much traction at
>>>>>>>>> present).
>>>>>>>>>
>>>>>>>>
>>>>>>> As I said above I don't see "blockchain" or "DLT" standardization
>>>>>>> happening soon. The industry is still figuring out the details and while
>>>>>>> there is still a feeling that there may be undiscovered opportunities
>>>>>>> around the next corner the prominent players are not going to fall over
>>>>>>> themselves to collaborate on a standard.
>>>>>>>
>>>>>>> And, for many in the industry the belief that a DLT provides
>>>>>>> interoperability is still widely held.
>>>>>>>
>>>>>>> Interledger is not a blockchain standardization effort. The amazing
>>>>>>> developments around value recording ledgers (like Bitcoin, Ripple,
>>>>>>> Ethereum) have provided the diversity of use cases to inspire a standard.
>>>>>>>
>>>>>>> In reality Interledger could have been developed to just work
>>>>>>> between traditional private ledgers but the desire to make it interoperate
>>>>>>> with public DLTs has been a key influence on the work.
>>>>>>>
>>>>>>>
>>>>>>>>> So Adrian, to give you a data point... I can't see anything
>>>>>>>>> clearly yet,
>>>>>>>>> but I know that we're going to be seeing more and more proposals
>>>>>>>>> for
>>>>>>>>> standardization over the next year and we'll see how those
>>>>>>>>> resonate with
>>>>>>>>> the community. I'm skeptical that we can do big "S"
>>>>>>>>> standardization and
>>>>>>>>> should instead be seeking little "s" standardization. I think
>>>>>>>>> things
>>>>>>>>> like Interledger, Chainpoint, decentralized identifiers, data
>>>>>>>>> models,
>>>>>>>>> and HTTP APIs are all we could suggest standardization proposals
>>>>>>>>> for at
>>>>>>>>> this point in time... and even then, they'll be rough for another
>>>>>>>>> year
>>>>>>>>> or three before we start to see some momentum. Just my $0.02.
>>>>>>>>>
>>>>>>>>
>>>>>>> Thanks Manu. With all this talk of standardization I worried that
>>>>>>> there was something I was missing. But it seems we're all in the same boat.
>>>>>>> Waiting to see where the tide takes this thing...
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>> Adam, are you in Perth for WWW2017? Pindar and I will be there
>>>>>>>>> tomorrow
>>>>>>>>> along with Tim and a few other blockchain folks. Perhaps we could
>>>>>>>>> sit
>>>>>>>>> down and have a chat about what we see as reasonable things to
>>>>>>>>> pursue in
>>>>>>>>> the next year or two?
>>>>>>>>>
>>>>>>>>> -- 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/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Mountie Lee
>>>>>
>>>>> PayGate -- Payment & Money Remittance Service
>>>>>
>>>>> Tel : +82 2 2140 2700 <+82%202-2140-2700>
>>>>> E-Mail : mountie@paygate.net
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Mountie Lee
>>>
>>> PayGate -- Payment & Money Remittance Service
>>>
>>> Tel : +82 2 2140 2700 <+82%202-2140-2700>
>>> E-Mail : mountie@paygate.net
>>>
>>>
>>
>
>
> --
> Mountie Lee
>
> PayGate -- Payment & Money Remittance Service
>
> Tel : +82 2 2140 2700 <+82%202-2140-2700>
> E-Mail : mountie@paygate.net
>
>