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

Hello All,

I am new to this community, but have been following this thread with great
interest. I am personally very bought into a decentralised and standardised
identifier for man, org and machine.

However I feel Reto has raised some very good concerns, and I would love if
the longstanding members of this community and those who have driven the
spec to what we have today, could reply to these concerns.

What are the economic incentives for implementers to store DIDs forever?
What stops method implementers not creating centralised and non SSI systems?

Looking forward to your replies!
Dennis

On Wed, Apr 4, 2018 at 9:09 PM, Reto Gmür <reto@factsmission.com> wrote:

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


-- 
[image: Vital Design] <http://www.mediaiqdigital.com/>
Dennis Yurkevich
5th Floor | High Holborn House | 52-54 High Holborn | London | WC1V 6RL
dennis@mediaiqdigital.com
tel +44 (0)20 700 0420 | mobile +44 (0) 7794 597783
[image: Twitter] <http://www.mediaiqdigital.com> [image: Blog]
<https://www.facebook.com/MediaiQDigital> [image: Facebook]
<https://twitter.com/mediaiqdigital> [image: LinkedIn]
<https://www.instagram.com/mediaiqdigital> [image: Foursquare]
<https://www.linkedin.com/company/media-iq-digital-ltd> [image: Pinterest]
<http://www.mediaiqdigital.com/inspirethroughinsights>
*Disclaimer: *This email and its attachments may be confidential and are
intended solely for the use of the individual to whom it is addressed. Any
views or opinions expressed are solely those of the author and do not
necessarily represent those of Media iQ Digital Limited. If you are not the
intended recipient of this email and its attachments, you must take no
action based upon them, nor must you copy or show them to anyone. No
contracts or official orders shall be concluded by means of this email.
Please contact the sender if you believe you have received this e-mail in
error.

Media iQ Digital Limited is a company registered in England and Wales |
Company Number 07321732 | VAT No: GB995910763