feat: add did:plc implementation

[alanshaw]

Adds a did:plc implementation that is compatible with ucantone and not atproto specific. PR also includes a resolver and client library for creating/updating/deactivating the DID.

Based on the spec: https://github.com/did-method-plc/did-method-plc/blob/main/website/spec/v0.1/did-plc.md

...and 2 existing reference implementations to verify compatibility:

• https://github.com/did-method-plc/did-method-plc/tree/main/packages/lib
• https://github.com/did-method-plc/go-didplc

[alanshaw]

Should be a string array per spec https://www.w3.org/TR/did-1.1/#core-properties

[Peeja]

Yeah, definitely shouldn't be DID. Possibly should be url.URL, though? It can't be just any string, it has to be…well, a URI, really, but that's what url.URL actually implements.

[alanshaw]

I have made it into a did.URL, which is a url.URL with JSON marshal/unmarshal.

[Copilot]

Pull request overview

This PR introduces a did:plc implementation (types + signing + resolver + directory client) intended to be compatible with ucantone without being atproto-specific. It also updates the core DID Document representation and context parsing for interoperability with PLC directory outputs.

Changes:

• Add did:plc data model + operation/tombstone builders, plus signing and signature verification helpers.
• Add a PLC resolver and directory client (fetch last operation, publish updates, deactivate).
• Update DID Document parsing/typing (alsoKnownAs as []string) and accept DID Core v1.0 context on input.

Reviewed changes

Copilot reviewed 15 out of 17 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
did/web/web_test.go	Updates did:web resolver tests for alsoKnownAs now being []string.
did/plc/types.go	Adds PLC operation/tombstone types and builder helpers.
did/plc/types_test.go	Unit tests for PLC type builders and CID-linking behavior.
did/plc/resolver.go	Adds a did:plc resolver that fetches documents from a directory endpoint.
did/plc/resolver_test.go	Tests for PLC resolver behavior and request construction.
did/plc/client.go	Adds a directory client for Last, Update, and Deactivate.
did/plc/client_test.go	Tests for directory client request/response handling, including tombstones.
did/plc/plc.go	Adds DID derivation (New) plus signing and verification helpers.
did/plc/plc_test.go	Tests for DID derivation determinism and signature verification.
did/plc/e2e_test.go	Optional e2e tests against the live PLC directory behind -tags e2e.
did/plc/README.md	Usage documentation for resolver/client and operation flows.
did/plc/gen/main.go	Codegen driver for CBOR and DagJSON encoders.
did/plc/json_gen.go	Generated DagJSON codecs for PLC types.
did/plc/cbor_gen.go	Generated CBOR codecs for PLC types.
did/document.go	Changes Document.AlsoKnownAs to []string and updates JSON decoding accordingly.
did/context.go	Accepts DID Core v1.0 context on input for interoperability.
did/context_test.go	Updates/extends tests for accepting v1.0 context and updated error messages.

Files not reviewed (2)

• did/plc/cbor_gen.go: Generated file
• did/plc/json_gen.go: Generated file

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[bajtos]

Where can I find more details about the did:plc scheme? Is https://web.plc.directory/spec/v0.1/did-plc the spec we want to implement?

[alanshaw]

Where can I find more details about the did:plc scheme? Is https://web.plc.directory/spec/v0.1/did-plc the spec we want to implement?

Spec: https://github.com/did-method-plc/did-method-plc/blob/main/website/spec/v0.1/did-plc.md

...and I've been referencing the 2 existing implementations to verify compatibility:

• https://github.com/did-method-plc/did-method-plc/tree/main/packages/lib
• https://github.com/did-method-plc/go-didplc

[Copilot]

Pull request overview

Copilot reviewed 15 out of 17 changed files in this pull request and generated 2 comments.

Files not reviewed (2)

• did/plc/cbor_gen.go: Generated file
• did/plc/json_gen.go: Generated file

[Peeja]

LGTM, with a couple of comments. The v1 one might be a blocker, though, if it means it won't work properly.

[Peeja]

Yeah, definitely shouldn't be DID. Possibly should be url.URL, though? It can't be just any string, it has to be…well, a URI, really, but that's what url.URL actually implements.

[bajtos]

TBH, I don't see why we cannot use the go-didplc implementation, but I'll trust your judgement.

I skimmed through the code and don't see any obvious issues.

I asked Claude to review the diff; see the comments below. None of them is blocking this PR from landing. The first one about map-key ordering looks important if it's valid, but it's something we can fix in a follow-up pull request.

[alanshaw]

TBH, I don't see why we cannot use the go-didplc implementation, but I'll trust your judgement.

Some justification for not using https://github.com/did-method-plc/go-didplc

1. The first thing the README states is "This codebase is pre-v1.0, there may be breaking API changes" so immediately I felt as though this library was not maintained and might not work.
2. Uses go-ipld-cbor which pulls in boxo, which pulls in go-ipld-prime - something we're explicitly trying to avoid.
3. Pulls in atproto crypto library https://github.com/bluesky-social/indigo/atproto/atcrypto and uses those interfaces for signing/verifying. Those interfaces that are not compatible with our multikey ed25519 or secp256k1 implementations.
4. Contains hard coded atproto specific keys and values for verification methods and services.
5. The client takes DIDs as strings, not a DID type.
6. The client has no facility to fetch the last operation - you have to fetch the whole chain.
7. Deals with legacy operations that we will never see.