RE: "Decentralized Identifiers": Bitcoin Cargo-Culture and Land Grabbing for the Top Level Names

On Wednesday, April 4, 2018 5:32 PM Dave Longley wrote:
> On 04/04/2018 07:40 AM, Reto Gmür wrote:
> >
> > Dave,
> >
> > You argue that I misrepresent DID in that it also allows for DHT based
> methods and that the spec might be adapted to support hash(pubkey) based
> DIDs.
> >
> > But what's left of standardized decentralized identifiers? DID is a URI super
> scheme that neither fits the URL nor the URN category of URIs, in that it is both
> a persistent name and allows dereferenciation. My impression is that the 2001
> distinction between URLs and URNs is quite obsolete, as HTTP-Range 14 has
> clarified HTTP URIs can be used to denote any kind of resource. It is also
> possible (and foreseen in the RFC) to implement decentralized and centralized
> URN resolver infrastructures.
> >
> > So why use:
> >
> > did = "did:" method ":" specific-idstring
> >
> > rather than the generic URI syntax
> >
> > scheme ":" hier-part [ "?" query ] [ "#" fragment ]
> >
> > ?
> 
> You may be missing some of the picture. Did you attend the CCG DID taskforce
> calls or read the minutes? There are some other aspects of the DID spec that
> have not yet landed. You will be at a serious disadvantage for understanding
> the spec if you are not actively participating in the group -- at least until the
> consensus has been translated into spec text.
> 
> For example, see some of those proposals are here:
> 
> https://docs.google.com/document/d/1aR8V_JUJdq1Sbi47wCV5aa-dEY0e-

> V2RqwPNP5ci1bg/edit
> 
> Please note that service resolution is a very important aspect of DID
> architecture -- and referencing services uses a common syntax across DID
> methods.
> 
> The DID spec is not "complete", it is a work in progress and we welcome
> further input. However, implementations for many of its features are moving
> forward because what we have so far is useful and because implementation
> experience is the best mechanism for ensuring the spec adequately delivers for
> use cases.

The question is, does any of the implementations fulfill the non-functional promises of the spec. Is there for example an algorithm that ensures highly redundant long term storage of identifier documents at low initial costs? For instance, what are the economic or other incentives for network participants to keep these documents in store for a long time (the spec says "forever")?

I mean I can propose the ZETTI ("zero energy teletransportation target identifier") URI scheme. Prepare a few slides on the bad consequences of transport that uses energy, is expensive, causes emission and takes time (causing harm especially to the most vulnerable in underdeveloped regions). I could then illustrate all the advantage of zero-energy teletransportation that is based on quantum entanglement (or other network) and specify the syntax:

zetti = "zetti:" method ":" specific-destination-string

The method MUST supports two operations TRANSPORT which performs zero-energy transportation based on quantum teletransport or other technology and a DESCRIBE operation that returns a JSON-LD document with a key "energy-consumption" of with the value SHOULD be "0" as well as other properties describing the transport to that target as it would be performed by the TRANSPORT operation.

He system is very liberal and supports many method. Apart from zetti:cern which is not yet capable of transporting bigger masses (above quantum level), there is zetti:uber and zetti:lyft. Of course none of this method is perfect, but there is a lot of work going on and in the end implementations drive the specification.

Before endorsing or even spending any effort in standardizing ZETTI I would like the following questions answered:
- Is there an actually available technology and possibly providers that offer zero-energy tele-transportation?
- Do targets for zero-energy tele-transportation need to be identified differently or could they use the same scheme as other transportation targets?

For DIDs it is very similar:
- Is there a credible technology that allows for decentralized identifiers with the describe properties and are there providers of such identifiers?
- Are there different requirements on the syntax for decentralized identifiers than for centralized identifiers?

So far I haven't seen a solution for the promises of DID. Like pointing to the dividends during the first years isn't enough to prove that an investment plan isn't a ponzi-scheme, just showing that a DID is still in a system after a while isn't enough evidence that the system actually fulfills the promises of decentralized identifiers. Instead of providing a clear explanation on how the money is invested a ponzi-scheme provider would add some complexity and another layer of indirection.

Reto

Received on Wednesday, 4 April 2018 20:10:09 UTC