Michael Muré

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.

Another new thing: github.com/MetaMask/go-...

It's a fast and simple (battery included) Decentralized Identifier implementation in go.

Currently it supports did:key, did:web and did:plc.

GitHub - ucan-wg/go-varsig: Multiformat for cryptographic signatures Multiformat for cryptographic signatures. Contribute to ucan-wg/go-varsig development by creating an account on GitHub.

It's time to announce properly some new things!

I just published v1.0.0 of github.com/ucan-wg/go-v..., the multiformat for cryptographic signatures. It's notably used in UCAN.

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 ...

Recursive hierarchical explainer for LLMs: starts with a high level concept ("explain database") and get a breakdown. From there you get an UX to expand as deep as you like on sub-topics ("LSM trees") in various ways: more explainers, implementation, connective question...

Does that exists?

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?

Random thought: full text search engine use word transformation, canonicalisation to map the input text to some internal index (my understanding).

Could a LLM vector space be used instead? That would remove the need for the transformations, and make it work cross-language.

Don't tell anyone, but my secret endeavor is to one day teach something to @expede.wtf instead of being schooled every time (which I enjoy dearly).

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

> Excited to try this.
> This is incredibly cool. I love seeing local first software starting to make a comeback.
> I've been yelling 'omg why doesn't someone build [...] for YEARS. This is wildly exciting.

More than coffee, those are what feed an open source project.

Hehe, git-bug making some waves again on hacker news: news.ycombinator.com/item?id=4397...

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?

Very interesting :-)
I'm on a slow quest to figure out a better DID system + social graph (if there is such a thing to begin with). As you are deep in there, is there something you would do differently?

You wouldn't nees those external scope definitions. You also get delegation for free, which enable some cool use cases.
A very different design for sure though, with different tradeoffs.

I found that a regular first leg of OAuth (social login up to getting the identity token) with a token exchange giving a UCAN token (instead of JWT) is a pretty powerful pattern.
Then you can apply the UCAN policies on HTTP parameters (path, arguments...).

Not necessarily a question for you but I'm wondering .. how much of that is portable beyond ATProto or Bluesky? The ideal identity system should be an agnostic base layer that works everywhere.

About the reputation, it seems that @cred.blue compute a score based on public data. I was more thinking about a reputation system where user actively vet others, or report bad behavior.
Ideally in a distributed fashion, where the score is "local" (your contact weight more on the score).

Thanks for the answer, at least I'll now research the PLC mirror. Curious where things are.

Any opinions around about what is or could be a good distributed social graph (aka: I know and can find other people) with reputation and DIDs? @bmann.ca maybe?

> "keep" their insta handle

This is a quite important point imho.

did:plc allows to use a DNS domain as handle with some DNS TXT entry that can be verified to prove ownership.

Can the same be done with insta and other service? What if the account get terminated?

@soatok.bsky.social thank you for all this material. Love the care you take to teach and tie together so many more gold resources for a curious reader.
My only regret is asking so late in the evening because how am I supposed to sleep now? My gears are TURNING.

I'll have a look, thanks. But really my question is analogous to how Bluesky should improve did:plc. There is already key rotation and revocation ... what can be done better?

For the context, I'm an engineer, not quite a cryptographer, and on the path to deploy some DIDs. Bluesky describes did:plc as a stopgap design, and I'm wondering what can or should come after. Any insights would be appreciated.

Could that be the base of an improved version of Bluesky's did:plc ? As I understand, did:plc is also an append-only chain, but without those extra features.