Re: A simpler approach to DID services and content-addressing

I think it unlikely that we have just those two use cases that Manu listed,
and that we should not use what (at least) feels like hard coded values for
specific use cases.  To have to add a new magic phrase (e.g.
:my_case:xxxxxx) for each new use case seems unnecessary when there are
options that are more open to innovation.

FWIW - the "type" use case is useful for Indy specifically - a method
specific use case. I suspect there will be many - including ones we haven't
thought of yet.

On Thu, Apr 4, 2019 at 8:13 AM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On 4/4/19 5:43 AM, =Drummond Reed wrote:
> > 1. The issue we saw with Manu's proposal is that there is no
> > syntactic delimiter between the "naked DID" (that identifies the DID
> > subject) and the parameters.
>
> The delimiter string between the "naked DID" and the parameters are
> ":path:" and ":hl:", for the use cases produced thus far.
>
> I did not do one for type because we haven't heard of an example where
> that is required, and if that existed, the processing rules would change
> to "first search for an identifier, then search by type". So, if that
> use case is important to folks, and it's not solved via an array of
> service endpoints (which is simpler), then we still have a solution that
> works.
>
> The other advantage is that we can still reserve the ";" for matrix
> parameters in the future, if we need them, but at this point, we can
> solve the use cases without using matrix parameters and thus keep the
> syntax for DIDs simpler.
>
> > 2. The only issue we had with Michael Herman's proposal is that the
> > syntax seemed heavier-weight (i.e., uses more delimiter characters)
> > than necessary, particularly for a URL grammar.
>
> I too would like to avoid the heavy use of complex microsyntaxes.
>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: Veres One Decentralized Identifier Blockchain Launches
> https://tinyurl.com/veres-one-launches
>
>

-- 

Stephen Curran
Principal, Cloud Compass Computing, Inc. (C3I)
Technical Governance Board Member - Sovrin Foundation (sovrin.org)

*Schedule a Meeting: **https://calendly.com/swcurran
<https://calendly.com/swcurran>*