I’ve heard some feedback that UCANs are a thing that people look at, but then don’t necessarily pick up as a tool. Obviously some people do successfully use them! This topic is to explore where adoption that could happen isn’t (and what we might do about it).
Some rough initial theories:
Inconsistency across implementations and tooling foot-guns; the libraries are easy to hold incorrectly and end up frustrated. This is probably a few easy fixes: more explicit failure modes, documentation, and with coming UCAN 0.10 / 1.0, we should set aside some time to make sure that all the implementations are consistent to avoid bugs that arise using UCANs across languages/libraries.
Unclear which bits to use and how – this is probably just a documentation thing, but choosing e.g., what aud to use and why, determining perms, etc.
I started this draft and then forgot about it so I’m just going to post it. I’ve made it private for the moment, but happy to open it up.
Recently, someone picked up go-UCAN and it is indeed stale.
I’ve flagged before that we need some recipes / cookbooks / templates that just basically describe how and where to use UCANs.
There are a few other things like serverless where you can build front ends that don’t need to store secrets, as a benefit.
Having one method for both client / account access as well as developer token
Ideally — this goes all the way to like a NodeJS server that is easily deployable that is UCAN enabled to show how to use UCANs for arbitrary bespoke services.
Idea (probably a couple of hours to implement a v0.1): UCAN Swiss Army Knife
A tool that will let you generate a UCAN, and maybe use that UCAN from the command line. It prompts you for a few things:
Issuer Private Key? (path, paste, or auto-generate & output and optionally save)
Audience? (same as above)
Capabilities: some kind of simple interface
Facts: same
prf is probably harder to build into a tool like this? Maybe v0.2.
Output: a UCAN! that can be used in a curl script or something similar.
