Why do people bounce off UCANs?

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.

@blaine this is in fact public and a good spot :wink:

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.

Not a fix per se, but one thing we could do is be more explicit about which versions of UCAN each library supports. Places to list this would be:

That way we at least save folks some potential frustration.

Yeah I think this should go on the backlog for the Fission CLI in Rust.

Might be great to start building exactly this around rs-UCAN and build up from there.

Opened an issue here: Add UCAN utility commands · Issue #50 · fission-codes/fission-cli · GitHub