So you're saying that because the spec is hosted at the W3C, it will break if the W3C goes down? Are you actually arguing that?
Discussion
In HTTP the live version is definitive. The kludge to get around that is that the context is hard coded in the spec and the sha256 is inserted
But if the data changed you'd have a mismatch, the kludge would pick the tie-breaker
The context also contains many links to other http resources. More vocabs and contexts. These provide things like data types (how do you know something is a date?) or to labels in different languages, plus inferencing
Those other schemas are not protected by the hashing kludge
I'm not saying it's bad. Just how it was designed. The system will work well enough
I am saying that nostr avoids all of this
It seems you're talking about JSON-LD, which is not required. You can use plain JSON and literally everything you're wringing your hands about becomes a non-issue.
More about the JSON-LD context
They did make this optional in the DID spec, but Manu says that he regretted it
There was a long talk about making it optional in the verifiable claims data model, but unresolved
https://github.com/w3c/vc-data-model/issues/947
FWIW: I think Gabe and Daniel are fighting the good fight there, but maybe without success
The context links to many other http files which are not sha256 protected from editing
Not wringing my hands a all. I spent a lot of time on DID so I hope it is successful. And I think it will work well enough
I'm just saying that nostr need not adopt DID because it can do just as well, if not better in terms of decentralization
Good news. TBD is not use JSON-LD in any of our Web5 architecture. So our work on DID/VC is completely unaffected by this limitation. In fact, even the *government* based pilots for DID/VC that we're seeing use plain JSON schema, too. Including the DHS's green card on VC program. So the issues you are raising just don't seem like a practical concern from a centralization/decentralization argument.
This is good
Let me just say that I was a JSON-LD evangelist for a long time. It would have been nice if it could have got to a critical mass. But there are some technical reasons why you might not want to use it
However I have come to recognize that some developers will want to use JSON. Instead of fighting it, we should just embrace it
I think this is a good way, and what has been described as the "big tent" approach
There is some devil in the details, tho. For example how do you express a date? And how is that canonicalized. Perhaps these things are being worked through.
Fundamentally what JSON-LD gives you is a standardized way of expressing hyperlinks (absolute and relative) inside of JSON
If not using JSON-LD, how to tell whether or not something is a hyperlink/URI?
Corollary: DIDs can interoperate perfectly well with nostr URIs by adding them to the JSON, and vice versa