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

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.


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
E-Mail : mountie@paygate.net