You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we utilize a did key from did-key crate, which is used to handle the public/private keys across this repo. However, the crate itself has questionable implementation and bad practices, which would require more work to refactor. Not to mention the spec itself is incomplete and looks to be more web focused (based on how many implementations handle it). Although theres another implementation, it may be best to strip this repo out altogether.
I would suggest replacing this with a inhouse key system that supports a couple of keys such as ed25516 (required for current implementations), ecdsa (for possible future implementations), etc.. This would be split into PublicKey and PrivateKey (or Keypair), which would allow for signing, verification, key exchange, etc.
Motivation:
Safer code base
Reduction in dependencies
Easier optimization and fixes
Simplify logic without the additional overhead
Note:
To maintain compatibility, we can keep DID, which we can pass to PublicKey to be decoded and encoded into such format, while allowing it to either as base58 or base64 encoding
Not priority at this time, but would be simple to do/implement
The text was updated successfully, but these errors were encountered:
Currently, we utilize a did key from
did-key
crate, which is used to handle the public/private keys across this repo. However, the crate itself has questionable implementation and bad practices, which would require more work to refactor. Not to mention the spec itself is incomplete and looks to be more web focused (based on how many implementations handle it). Although theres another implementation, it may be best to strip this repo out altogether.I would suggest replacing this with a inhouse key system that supports a couple of keys such as ed25516 (required for current implementations), ecdsa (for possible future implementations), etc.. This would be split into
PublicKey
andPrivateKey
(orKeypair
), which would allow for signing, verification, key exchange, etc.Motivation:
Note:
DID
, which we can pass toPublicKey
to be decoded and encoded into such format, while allowing it to either as base58 or base64 encodingThe text was updated successfully, but these errors were encountered: