chore: Expose account keys #144
Conversation
| /// Get the keys of this account. The public key can be retrieved from the secret key. | ||
| pub fn keys(&self) -> SecretKey { | ||
| SecretKey(self.signer.0.secret_key.clone()) | ||
| } |
There was a problem hiding this comment.
I think it is fine to only return SecretKey, but I would argue that keys is not a good name in this case because of plurality. Maybe just key or secret_key while leaving the clarification that public key can be retrieved from the secret key?
There was a problem hiding this comment.
Also, noting it's probably best if we keep this representation internally, and then this method can return &SecretKey. Cloning implicitly feels weird
There was a problem hiding this comment.
Gotcha, I'll re-work how InMemorySigner is represented internally but shouldn't be too big of a deal to expose it as a &SecretKey
There was a problem hiding this comment.
alright should be good. Ready to be re-reviewed whenever you guys get the chance
Reading in between the lines, but I'm guessing you meant to say how does the |
Addresses #142
Exposes the account keys. Might be a little weird that it's exposed just as a
SecretKeytype instead of something like aKeyPairtype. This is due toSecretKeybeing aKeyPairitself containing thePublicKey. WDYT? Is the return type good enough just asSecretKeyor should we do something like(PublicKey, SecretKey)?