This repository was archived by the owner on Oct 28, 2025. It is now read-only.
Repository navigation
This repository was archived by the owner on Oct 28, 2025. It is now read-only.
lastChunkHandling: strict-no-padding option? #62
Description
Would be useful for deterministic or multibase-adjacent usage where there is clear separation between base64 (which omits padding) and base64pad (which does include padding).
Right now the only way to mitigate this is to manually check if there's a padding and throw if that's the case, but I wonder if this is better handled as an option in lastChunkHandling instead?
It seems weird to me that omitPadding was added in the encode side yet no equivalent option in the decode side.
Activity
bakkot commentedon Jan 7, 2025
No one had a use case for it. The relatively rare places which care about canonical encodings generally also enforce presence of padding, in my experience. Also, it's easier to check for padding when decoding than to generate it when encoding.
mary-ext commentedon Jan 7, 2025
Hrmmm, unfortunate, there is a few more things I'm noticing that hampers the use in IPLD/DASL/AT Protocol context (without tacking on additional code, as mentioned above.)
I'm wondering if I should just file them as separate issues, or mention it in here for now as the overarching issue is the same (determinism requirement)
base64should...Uint8Array.fromBase64('A')should throw instead of returning an empty uint8, it doesn't seem likelastChunkHandling: stricthandles this?)base16should...base16upper)bakkot commentedon Jan 7, 2025
This proposal is no longer making changes except for bugfixes. You're welcome to mention use cases here, but they'd have to be done in a follow-up. That said, these were all discussed and we explicitly decided they weren't worth adding API complexity for, given that they're all straightforward to do in userland.
Except this one. That should be an error in anything except
stop-before-partial. If you're seeing otherwise, that's a bug in whatever implementation you're using.