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

so the URI can be adaptable for representing identifiers
but for the data format, we have no consensus.


On Mon, Apr 3, 2017 at 7:32 PM, Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

>
>
> 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
>>
>>
>


-- 
Mountie Lee

PayGate -- Payment & Money Remittance Service

Tel : +82 2 2140 2700
E-Mail : mountie@paygate.net