haha would be a great name for a revocation library at minimum. When you work with UCAN, you start to realise how often you say "you can" in daily life 🤣 Also, the community call is named "WeCAN" 🦜🤝🦜

But overall, if I'm reading it correctly and translating a few details, this is absolutely how UCAN is meant to be used 🎫🦜✨

oh I see haha yeah that makes sense. The good news is that you can tell it to read the specs and it'll catch up pretty quick.

Also just a terminological thing:

> the application requests a UCAN attestation from the verification service upfront.

This should be "UCAN delegation" not attestation

GitHub - ucan-wg/spec: User Controlled Authorization Network (UCAN) Specification User Controlled Authorization Network (UCAN) Specification - ucan-wg/spec

I wonder if you're looking at some old writing on UCAN rather than the current specs? Here's the top level spec which links out to sub-specs github.com/ucan-wg/spec

> into a UCAN — a JWT signed by the verification service's DID

UCAN hasn't been a JWT for some time. These days it's a bespoke DAG-CBOR format.

Hooray! Reading now. I'll put comments in this thread as I go

Oh nice! Thanks for the link :D

You made it to #twir!
this-week-in-rust.org/blog/2026/04...

Ah indeed, I know it well! The incomparable ✨ @dustyweb.bsky.social ✨ is one of the editors of zcap-ld

Surelock I hate deadlocks. Maybe you do too.

🦀🔐☠️ Tired of deadlocks? Me too! Here's a post about a library that I've been working on to help wrangle the problem in Rust

notes.brooklynzelenka.com/Blog/Surelock

A Cryptography Engineer’s Perspective on Quantum Computing Timelines The risk that cryptographically-relevant quantum computers materialize within the next few years is now high enough to be dispositive, unfortunately.

Two papers came out last week that suggest classical asymmetric cryptography might indeed be broken by quantum computers in just a few years.

That means we need to ship post-quantum crypto now, with the tools we have: ML-KEM and ML-DSA. I didn't think PQ auth was so urgent until recently.

I used to do that from an iPad a few years ago between laptops and honestly it worked great (in part because I use terminal emacs), but there were juuuust enough times travelling and I'd lose connectivity on a train etc. Great setup otherwise, should be more common imo

Thanks 🤝 and yes indeed NixOS ❄️ just tweaked my desktop config a bit, pulled, built, and I was back in action 💪 moving several hundred GB of files from my Mac is taking... longer

I hope that framework comes out with more colourways for the chassis on the 13 this year 🤞

I looked very seriously at the 12 since they're ADORABLE, but they're just not powerful enough to compile Rust quickly all day :/

An open box of framework laptop parts on a counter

The set up framework 13. It has a translucent purple display bezel, shows the time 19:06 on the desktop, and has an illustration of a cafe for the wallpaper that says ロ－フィコーヒー (LoFi Coffee)

So... it begins 🐧 ❄️

I also like the use of 2 phase commit — I agree that the current revocation semantics need that. You could get fancy and move this check to the client with negative proofs to take load off the server, but probably too deep for a v1 🤔

The deep integration with ATProto concepts is nice — I think specialising in this way will help with adoption since it'll plug into the rest of the ecosystem tooling etc

> No revocation infrastructure. No coordination required.

I think this claim is somewhat overstated. The PDS here is acting as a revocation oracle. If I'm reading this correctly, you must access the PDS — that is both infrastructure and coordination

The difference is that UCAN generalizes across topologies while Capability Trees specializes to ATProto's PDS deletion semantics.

Hmm 🤔 The UCAN revocation spec isn't underspecified — it says that that the agent controlling the resource is the ultimate authority on revocation, which is the same locus of control as what you describe here

This is all to say: sure I haven't seen much novel in this thread, BUT WELCOME! You could likely use or adapt an existing system, but I'm a fan of letting a thousand flowers bloom! Happy to review your design in more detail as it evolves and share how we and others have approached similar designs ✨

Caps are a very natural design (people keep reinventing them) and are a Good Idea™️. The first UCAN was not aware of the lineage and it shows. Then we fixed it up. Years later we started adding actual novel things. It's great to have so much history to learn from -- we learned a lot!

Back to your original question: is anything novel in here? Not as far as I understand. The 404 strategy is also very standard. BUT! I started the same way with UCAN. Christine has a similar story with Goblins. Alan Karp (capabilities OG) has a similar story from the early 2000s

Sure, but the node 404ing itself retains a list of revocations, right? Or am I missing something?

An optimization we did in UCAN: if you have a caching layer, then the invocation only needs to contain the CIDs of the complete chain. They *can* include all of the delegations in the message but thanks to DAG-CBOR + CIDs they don't have to (you can save a bunch of bandwidth and verification time)

For revocation, the revocation list is generally a set of certificate IDs to both honour anymore (until they expire at which point you can garbage collect them) -- here that would live on the PDS. Does the proposal work differently for revocations?

Unless I'm misunderstanding something, the chain rooted in a resource server is how these systems generally work, so that part isn't novel

How does the PDS track revoked capabilities in your model?

🤔 also AFAIK "possession is sufficient authorization" is not accurate for any modern distributed capability system (e.g. intercepted UCANs cannot be used by the intercepter)