-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add go package as a submodule #220
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Tiago Nascimento <tiago.nascimento@spruceid.com>
Signed-off-by: Tiago Nascimento <tiago.nascimento@spruceid.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! Go tests passed. Example program builds and runs. For the example program, instead of using submodules for ssi
and didkit
, I used symlinks to my existing copies of them.
Other ideas:
- If users of the didkit go package must have a local copy of ssi and/or didkit (as submodules or otherwise), could it be useful to have an example repo demonstrating this usage?
- For the other didkit FFI libraries we usually have tests in GitHub actions. If not adding them here, should an issue be opened for this?
- The other didkit interfaces are in this repo directly, while this one uses a separate repo which is included as a submodule. Could it have been included directly? I assume it did not work to do so, but wonder why.
|
CI was added; thanks @w4ll3. Tests still pass after merging in changes from main (2eb854d). The submodule didkit-go repo looks good to me. I tried using the example more, and was able to get a verifiable credential, but was not able to present it. Also, I don't know if it makes sense to use a DID as the verifiable credential id. Usually a DID is an id of a DID document, and a verifiable credential is not a DID document. In this case the keypair associated with the DID used in the VC id is not stored, so it does not appear to serve a useful purpose (e.g. for signing/verification). A UUID could be used instead - or the id property could be removed if the app doesn't need to store/retrieve the credentials by id. For the sake of enabling didkit-go, I think this PR could be merged as-is and new issues created to track these things. |
This adds a sub module to DIDKit didkit-go. The reason it is being added this way is to make it possible to be used as a module in a Go program. Once this is merged the instructions at didkit-go, which are simpler, will work.
Testing at DIDKit
How to test it on a Go program
Testing example application