Update and new maintainers for go-ucan

[bmann]

The go-ucan library was the first implementation outside of Fission, by @b5.

We have heard from several people that there is interest in having an up to date

What we'd like to do:

• let us know in this thread if you're interesting in using a go-ucan library -- and what you want to use it for (e.g. we've heard the Saturn team is looking at it)
• if you're interested in doing the development work / maintenance work on this library, leave a comment -- we'll be looking to pool some funds / apply for some grants so that maintainers can keep it up to date over time

[bmann]

@b5 let me know that he'd be happy to do a code overview with anyone that takes this over, and spend some time reviewing new code

[taoshengshi]

@bmann I and KEN Labs is willing to take over go-ucan's work, including but not limited to code review.

[bmann]

Great! And by code review @b5 juat offered to help hand off the current code base since he wrote it.

[nustiueudinastea]

Hey @bmann has there been any progress in handing this over to Ken Labs? Interested in adopting this as well and was wondering. Thanks!

[smoyer64]

Please add me to the list of invitees ... TY

[fabiobozzo]

Me too, please 🙋

[smoyer64]

@bmann I've added support for secp256k1 keys in my fork at github.com/selesy/go-ucan and if there is interest, I'm happy to merge this back into the "official" project. Do we have one yet or should I just allow my fork to continue to diverge?

[taoshengshi]

@bmann I and KEN Labs is willing to take over go-ucan's work, including but not limited to code review.

Just share the latest implementation of go-ucan:

KenCloud-Tech/go-ucan-kc
https://github.com/KenCloud-Tech/go-ucan-kc

[bmann]

Noting here: this has come back to @smoyer64 wanting to take over the codebase

I know it's stale and I know that v1.0.0 will be a rewrite but I'd like to merge my iimprovements to the v0.7.0 version first and continue in the canoncial namespace

I strongly recommend against it, including that you would be inheriting the license choice of GPL (I’d suggest MIT / Apache)

@smoyer64 if you still want to do it, I can make you a maintainer, but I would suggest just a brand new repo — which you’re welcome to keep here in this org if you like.

[smoyer64]

I strongly recommend against it

inheriting the license choice of GPL

Ouch - somehow I missed that. Can we create a new repo for v1.x.x work and I'm still happy to merge my secp256k1 code back into this repo if anyone wants it.

[smoyer64]

@b5 added Fabio and I to this repo but could you create a new repo and add us there as well?

[bmann]

@smoyer64 create your own repo, check in your code, make me a maintainer of that repo, and then I can transfer it in here.

(sorry for delay, IETF and local events in Vancouver this week)

[smoyer64]

The go-ucan license was changed and we can proceed using that repository.