v1.0 Planning

[expede]

In the Oct 2022 community call, there was much interest in the signalling behind releasing a UCAN v1.0 in the coming months. If we make substantial changes to v0.9, we should create a v0.10 ahead of the v1.0, but it's entirely possible that we simply promote v0.9 to v1.0.

(The items below are based on conversations, and being on this list is not an endorsement)

• Actively work on community interop "for real"
  • e.g. Fission <-> web3.storage <-> Noosphere
• Is there anything that v0.9 is missing?
  • Generalize principals to any URI? (i.e. more than DIDs)
• Is there anything that v0.9 has but shouldn't?
  • Fix holes in revocation section!
  • Proof pipelining
  • Remove fct section?
  • Replace ucan: URI scheme with a non-URI one?

[burdiyan]

As an outsider trying to get into the details of the spec, one thing that took me a while to understand is the actual meaning of with and can fields. I think it would be much clearer if they were nouns like resource and ability or something similar (maybe shorter). I generally prefer nouns as field names (e.g. author vs. written_by), so I might be biased, but to me it is much more understandable this way. Also I think that it’s the reason why it’s and issuer (well, iss) and not who or something like that 🙂

So if there’s some willingness to introduce a breaking change to the spec before v1, maybe this is something you’d find useful.