Re: DID Spec Hardening Proposal V3

Christopher Allan Webber writes:

> Dave Longley writes:
>
>> Chris may have more to say about how this would be useful for addressing
>> decentralized social media portability.
>
> Well, we need a way for paths to be meaningfully retrievable.  If we
> were going to use DIDs as a namespace for a user's objects on an
> application participating in ActivityPub, we'd obviously have to know
> how to retrieve them. :)

BTW one of the other things that we talked about at TPAC was about the
json-ld / simple json requirement.  When it was Dave, Drummond and I
sitting around the table I thought we got a pretty clear understanding
that every provider needs to uphold *both* at once:

 - Emitted JSON-LD should be written in such a way that it can be
   understood by naive json consumers
 - But the JSON emitted must also be valid JSON-LD, including that all
   terms must be unambiguously mapped by the @context.

It isn't too hard to do both.  I get the impression looking at the
latest DID Hardening spec though that we're seeing some people pushing
for the former without also expressing to uphold the latter.  Both of
these can, and should be supported.

If we don't do the former, we'll lose out on a lot of users who are
using more simple toolkits.  If we don't do the latter, any DID method
implementor that fails to produce valid json-ld simply won't be used by
many what-would-otherwise-be enthusiastic adopters.  For example,
users from the ActivityPub distributed social network *have to* be able
to consume valid json-ld... if for some reason your method doesn't
produce valid json-ld (which isn't too hard, even if you use naive json
tooling to output it!  often it's as simple as including a @context)
then we'll have to use the other methods and not yours.  That would be a
real bummer!

Received on Monday, 27 November 2017 18:47:30 UTC