It's public if you want to play with it: cad.onshape.com/documents/04...

Cool list :-)

I'll take the occasion to ask a slightly different question: what do you think is the paper (recent or not) with the most practical potential, to do something better or novel? In particular in the realm of protocols, but feel free to extend further.

Another cool thing is that because all the crypto and DID verification methods included, it's quite easy to add more DID types. Implementing did:web took 2h.

The hard part was to figure out that the examples in the spec are invalid.

This crypto package could be split into its own thing if there is interest. Do you think that's useful standalone?

In particular, it contains all the cryptographic handling to make it dead easy to consume DIDs, validate signatures and so on.

If you tried to use different key types with the go standard crypto library, you know it's a minefield of mismatched API.

github.com/MetaMask/go-... fix it.

This could also be used to explain a codebase:
- start from some entry point question
- get a break down of the data flow or call graph
- click around to get more details
- asks more about language feature, pattern, capability, dependencies ...

Disclaimer: no idea if that actually makes sense.

I suppose the high dimentionality would make the index less compact, but maybe techniques like principal component analysis could compress that space, yet retain enough information for full-text search?

Funny that we reconnect like that. Thanks @bmann.ca for being that social catalyst once again!

I'm not too familiar with it (yet), but why not use Verifiable Credentials, that comes often in DID systems and is heavily standardized, instead of rolling your own format? As I understand it's more or less the same thing: a signed claim.

There is also a token container (with a spec) that abstract the encoding and optional compression. Great to fit into a HTTP header or other medium.

FYI, I have some tooling around go-ucan to apply UCAN policies on HTTP request parameters (host, path, query ...) or JSON-RPC ... that I plan to migrate into go-ucan. The idea is to have a somewhat standard way to apply UCAN on pre-existing HTTP APIs. It'd be great to be all on the same page.

Definitely agree on the "centralized" aspect.

About the certificate logs, as did:plc has a chain of signed operations containing all the data ... isn't that already a certificate log? Could you expand your thought?