Hacker News Reader

Comment by Taek | Hacker News Reader

I've been following DID for a while and I really don't think its the right approach. The voices of concern from Mozilla and Google are spot on: the DID specs expect everyone to coordinate on finding the right structure for different types of data but the real world is messy and no "correct" structure exists.

DID in my opinion is unlikely to succeed. Real builders don't use it, because it is cumbersome and requires agreeing with (a step up from collaborating with) other opinionated developers who have different specific use cases in mind.

View on HN

> but the real world is messy and no "correct" structure exists.

Then why would we expect Mozilla or Google or anyone else on that committee to ever determine one? Or to object to a free-for-all naming scheme if the problem is inherently ad-hoc?

Whether or not this standard succeeds, one can see the very real threat of standard capture here. Which has happened before, on numerous occasions, when a canonical implementation arrives that just so happens to prioritize their interests.

> DID in my opinion is unlikely to succeed.

Probably a few big tech companies will form a consortium and use their weight for setting a de-facto standard.

Putting the centralized in decentralized.

Probably so. Centralized isn't always a bad word as you can see from the tire fire that is crypto.

Most crypto is fairly centralised, ironically.

Or they won't use it and will be confined to a long tail of use cases?

I mean, not all of the Internet is accessed through a browser but if Chrome and Firefox don't support DIDs, even if Safari would, who would use DIDs in a context exposed to browsers?

Apple objected too I think.

Maybe usage will converge on a few dominant methods (be it did:key, did:web or some other one), based on successful applications. This is pretty similar to URIs, which were defined very openly, and where for instance http(s):// took over gopher:// and ftp://

> This is pretty similar to URIs, which were defined very openly, and where for instance http(s):// took over gopher:// and ftp://

Urls were defined way after all those things, and were predominately created by the http people. I don't think its similar at all, and regardless, compared to the actual http (or gopher or ftp) protocol, the url syntax is the least interesting part.

A better example perhaps is `www` or `mail` or `news`. Or magnet links. Or JWT on top of JSON.

In the era of The Information Superhighway, the World Wide Web, and spinning Netscape comets, people were quite ok standardizing on `www` as a prefix that used dns to route your web traffic to the web server. Meanwhile, AOL had a concrete use case of "keywords" that monopolized tv ad time for half a decade and went nowhere.

The web is full of standards that exist on top of other standards. This standard allows people to name things. People will figure out how to make interesting use cases with names without a central authority finding pre-existing use cases.

What exactly are you saying? That DID is as useful as an optional naming convention for server names that some people liked to use in the 90s?

If that is the comparable case, what is the value add of w3c standardizing this?

Personally this standard sounds closer to SOAP/WSDL/etc to me.

Reply on news.ycombinator.com