Why do people bounce off UCANs?

Developers UCAN
1

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.

2

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