dot-asm
commented
1 year ago if there's a reason these aren't already implemented.
Thing to recognize is that we are not a "Rust shop" and as a result have kind of a blind spot for rustaceans' expectations:-) Suggestions are welcomed, but we have to balance them against the naturally limited capacity to maintain things. For this reason the preference is to focus on things that actually matter as opposed to meeting might-be-useful requests. For example a suggestion to serialize blst_fp6 would be disputed. I would even argue that it's no point to serialize any of blst_fp*. Or in other words, the suggestion would be to draw the serialization "boundary" at EC points, a.k.a. signatures and public keys in the context. As for the keys, I for one am actually torn about it. I'm generally reluctant to generalize about the secret key handling, minimize the interface to absolutely required minimum, and let the application work it out according to whatever security requirements it aims to meet... Thoughts? Maybe we can compromise with a discouraging feature name like 'not-for-production'? As for features. The preference would be to have even the non-secret-key serialization as a feature. Which should be easy to arrange... To summarize,
would you be open to a PR that adds serde support?
Yes:-)
Cheers!
kwantam
Thanks for a fantastic library!
It would be really helpful for me if signature and key types had serde serialize/deserialize implementations (presumably threaded through the existing serialize() and deserialize() functions). But I know y'all have thought about this much more than I have, so I wonder if there's a reason these aren't already implemented.
If not, would you be open to a PR that adds serde support?
Cheers!