Oddbean

That's simply due to poor implementation. Not due to the standard. The named types are part of a set of standards, not defined in VC. Frankly, most of the VC folks didnt read the specs, and that was most of the problem. Take for example schema.org which uses strings for types. It uses the same standards and achieves many orders of magnitude more interop then nostr. That's just one project that uses the standards. But it's all good, nostr can use both numbers and strings for types in different contexts, via websockets, and the web. For example: https://w3id.org/nostr

My point is that the standard can massively help interoperability. The VC standard leaves it to the implementers, which is terrible because, like you said, they REALLY suck at this. What more proof do you need than 175 different did methods? We have 3 separate Bitcoin DID methods alone. If our closed community can't even agree on this, imagine the rest of corporate devs that have no incentive to work together... It's the same issue in Health Care with HL7/FHIR data. The standard is cool, but unhelpful to keep implementers looking at one another and reusing their way of doing business. Zero interoperability, even though everybody offers the same type of payloads.

Agree with the first part. They even gave lots of bogus examples so people were copying and pasting things that were not best practices. DID got messed up even worse, but was not designed to do that, I designed it to make a uniform interoeprable interface for the bitcoin block chain, but it got co-opted. But the lack of interop doesnt come from named types. There is lots of other technical debt, bad examples, and deviation from the standards. The named types are probably the one useful thing in there. ActivityPub uses named types and its growing faster than nostr. I do like the nostr number system, because its simple and works. But if you had an OO system and every class was a number, it's going to struggle to scale at some point. Numbers work well because nostr is early and small. I was actually thinking of rewriting the whole of DID and VCs, taking the good bits for nostr. It might happen one day, but magic numbers vs types is not really a deal breaker. Plenty of other things are tho. VC/DID is frankly a mess, the data structure is a set, no arrays, no canonicalization, the examples are wrong, the context breaks everything, the document is not defined, no one knows how to make a vocab excapt dave and manu. Even they cut corners. The list goes on and on.

I roughly know that is needed, this time round - take the taproot data model and apply expand ways it can be used - structured profiles that can have developer defined extensions, e.g. for subkeys - tighter integration with on-chain transactions allowing timestamping, versioning and smart contracts - uniform caching and scaling interface, layered, stateless, with CDNs and proper etags - proper json based data models with schemas that work, can be versioned, have an audit trail - schnorr signatures over simple json data structures, as today - lightning fast profile and roster apps, allowing things like chat - personal storage, access controlled - everything payments ready, with audit, and observable reputation - close AI integration so that nostr builds itself - proper web of trust including punishment zaps for bad actors, spammers, scammers - wide range of micro apps, including chat - incentive structure to support long term growth, on a level playing field and so on ...