`lastChunkHandling: strict-no-padding` option?
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?
https://github.com/mary-ext/atcute/blob/bde458b1ad33b9d0ede8975383301b7faa4194cd/packages/utilities/multibase/lib/bases/base64.ts#L15-L21
It seems weird to me that omitPadding was added in the encode side yet no equivalent option in the decode side.
It seems weird to me that
omitPaddingwas added in the encode side yet no equivalent option in the decode side.
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.
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...- not contain paddings (this issue)
- not contain whitespaces
- should throw if chunk only contains one character (
Uint8Array.fromBase64('A')should throw instead of returning an empty uint8, it doesn't seem likelastChunkHandling: stricthandles this?)
base16should...- only contain lowercase letters (uppercase would be
base16upper)
- only contain lowercase letters (uppercase would be
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.
Uint8Array.fromBase64('A')should throw
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.