Mozilla and Google Objections Overruled on “Decentralized Identifiers” by W3C

The biggest problem is that getElementByID doesn’t fucking work.

And then if you sign sibling documents, you essentially have most of the same problems you have with ensuring a zip file doesn’t have a malicious payload, because file cannonicalization is fraught with issues.

It took me a couple pages of don’ts to nail it down, and I missed a big one that I didn’t see until pretty late in the project.

1. If you're sending a portion of your monthly wages as a remittance to your family, spending a dollar[1] isn't too much.

2. A smart contract allows decentralised organisations to function, with democratic voting and transparency. (That's not appropriate or necessary for every organisation, but it can be an improvement on one person hosting a server and saying "Trust me"). If there's a bug in the contract, you have to vote to change the contract. Traditional contracts, businesses, and even countries fail all the time, but we haven't give up on them as concepts.

3. For a concrete use-case, I offer the example of blockchain technology being used to make the fishing industry supply chain more transparent.[3] It's true that someone could enter fake information onto the blockchain, but they could also fake signatures on paperwork, so a system can still be useful even if it doesn't prevent all possible attacks.

4. If the ledger isn't trustless, then someone is controlling it, so your identities aren't really decentralised.

5. There are better currencies than BTC if transaction costs are the main concern. The equivalent number for BCH is half a cent.[5]

[1] https://bitinfocharts.com/comparison/bitcoin-transactionfees...

[3] https://www.reutersevents.com/sustainability/using-blockchai...

[5] https://bitinfocharts.com/comparison/bitcoin%20cash-transact...

I understand that the list presented there is more-so early stage proposals; its not like they've been registered to manage that DID method.

That being said; it speaks some amount to the professionalism of the authors and supporters of this spec. The sane people ask: what are the real, tangible use-cases? There's no answer. Ok, well short of that: are there are least real, tangible organizations who will be building on top of this?

Not only is the answer weak, but the meeting notes from the DID-WG indicate a high level aversion to any known, named authority participating in a significant capacity [1]. They were rather concerned about Mastercard's proposed "id" DID method, for privacy/centralization reasons, maybe those are valid but...

> Markus Sabadello: … Even if we don’t apply it, since in the past we haven’t, even then I think this registration should not be accepted as-is, because it’s incomplete..

> Manu Sporny: Just about every DID Method is incomplete… not a good criteria..

It really comes off as a bunch of people who are mad at the centralization of big tech, want to change it, but lack focus & expertise on how to implement that change. And they managed to drag W3C/TBL down to their level.

[1] https://www.w3.org/2019/did-wg/Meetings/Minutes/2022-01-11-d...

Sorry, but you sound like tech skeptics in every generation ever, saying “the Dewey Decimal system works perfectly well, why do we need computers just to find a book”? (Yes, I have heard this exact objection raised by radio hosts to early computer pioneers who tried to explain why computers will become useful for regular people.)

Email became useful and replaced the post office

Web 1.0 became useful and replaced TV, radio, magazines

Web 2.0 became useful and allowed people to communicate but still hasn’t been truly decentralized

What makes you think that Web3 replacing trusted gatekeepers is not useful? You think “just trust me” is the best system we can possibly have for writing code that does some business logic?

For me it’s simple: if there is something that’s very valuable (some NFT, some role, some election, some large balance of USDT) then I prefer that my customers custody their own keys and deal with that themselves. Less liability for me. Rather than having a guy with keys to the database log in and potentially change the result of an election, and having to track down logs and deal with lawsuits etc. I just want smart contracts to deal with it, and each participant can only take the actions they are allowed to take - no exceptions. No central point of failure for security. No need for audits OF TRANSACTIONSby auditors who can also be corrupted.

How do we make sure that smart contracts are correct? Audits, battle testing and with Cardano we even have provable correctness. UniSwap likely has no exploitable bugs, for instance, or they would have been found. Every instance of UniSwap AMMs comes out of the same factory. THE END RESULT is far more reliable than any code that runs on only one machine by a “trust me” corp.

Sorry buddy, you can shill your centralized “trust me” all you want but you sound like Peter Schiff and his gold. You just don’t get it.

1. No liability for transactions, only for code

2. Open source infrastructure

3. No central entities who can corrupt the system in unlimited ways

4. People can only do what is allowed, no matter what

5. Code operates regardless of whether the central entity is around in 20-30 years

6. Different incentives (selling tokens is far more user-friendly than selling shares to a parasitic investor class that will cause you to extract rents forever and introduce dark patterns and lockin at the expense of the public).

7. Interoperability — on-chain data can be used for other smart contracts and any websites can read the data.

8. Global interoperability, no need to rely on a patchwork of currencies and money transmission legs and banks that Stripe takes care of for you. USDC is an ERC20 token and you write code, not connecting to a billion little APIs. Similarly to HTTP letting you go worldwide vs what Twilio had to do for you, or negotiating syndication by radio stations.

Of course I think blockchain is a first-gen technology but it enables this and a lot more !

> never works as it should.

Not only that, by exploiting ambiguities and gaps, protocols can be made to work as they shouldn't. At least that keeps the security consultants in business.