
Thanks for the knowledge regarding the size of the ByteString! Eventually the outside serialisation isn't up to me, but rather the consumers. I have one potential user who told me they need the signature and the message to be separate for the protocol they are implementing. I guess if I defer to ByteString early on it'll be easier for the library to be adapted to whatever use case comes after. Thanks a lot Viktor, I believe I'll go to bed less ignorant tonight. :) Le 28/11/2022 à 20:34, Viktor Dukhovni a écrit :
On Mon, Nov 28, 2022 at 08:14:15PM +0100, Hécate wrote:
Ah sorry, I misunderstood your question.
I am writing a high-level interface to my libsodium bindings, and I'm trying to provide implementations of helpful typeclasses.
I actually don't need Storable to do the FFI stuff, thankfully, but the main case of using this library would involve sending the result of the signing operation to the network (as ByteStrings), with authorization tokens like Biscuit¹ in mind.
¹ https://www.biscuitsec.org For serialisation to external standard formats, like JSON, or binary JSON, ... you're definitely not looking for `Storable`. Simply returning the message as two octet-strings (ByteStrings), one for the raw data and another for the signature is all you need. From there, various higher-level formats are possible.
The main thing to be mindful of is that ByteStrings are limited to 2^31 bytes on 32-bit machines, so very large messages don't fit in a ByteString on some (increasingly less common) architectures.
Or am I missing some reason why you'd want to create a single binary blob
,<signature>>?
-- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD