Make BEGIN and END tags easier to type

[bwbug]

For use-cases in which the shares will be distributed in hardcopy and manually typed for decryption, typing in the current BEGIN/END tags is unnecessarily cumbersome (especially with arbitrary requirements such as having to insert exactly one space character before S4 in the BEGIN tag but having no space after the ] bracket).

My suggestion is to simplify the tags, and to also allow some variability in the allowed use of whitespace within the tags (specifically, make all whitespace optional, by stripping whitespace before further parsing of the inputs). In addition, I would suggest not using the Base64 padding character (=) within the BEGIN/END tags, so that the line breaks can be made optional.

For example, I might suggest the following format:

[s4|v0.5|S4:YsVweIrrKfDotKXSTt4hGc2PZrwBJli1x8s25XkzlBkBLPc=]

If whitespace is stripped before processing, then optional line breaks (and/or indentation) could be inserted:

[s4|v0.5|S4:
    YsVweIrrKfDotKXS
    Tt4hGc2PZrwBJli1
    x8s25XkzlBkBLPc=
]

If you feel the need to keep the BEGIN and END keywords, then I would suggest making their use optional, as well:

[BEGIN|s4|v0.5|S4:
YsVweIrrKfDotKXSTt4hGc2PZrwBJli1x8s25XkzlBkBLPc=
|END]

[qgustavor]

Thinking about better UX for manual writing/reading, an encoding scheme made with this in mind could be used, like Base58, which omits similar characters like O and 0, l and I and so on. Even when printing, using Base64 requires a font that allows distinguishing those characters. Of course, a more lenient wrapping format would be useful when dealing with pen and paper users. Alternatively, using a word list to encode (like BIP39) seems useful.

Those are all options that could be integrated without too much difficulty editing this file and can be an option, current mode being "the shares will be transmitted online" and the new mode "the shares will be transmitted in paper". As someone that only knows a bit of Go from working with other repos, I'm amazed at all those ninja comments. :eyes:

[bwbug]

Those are all options that could be integrated without too much difficulty

The biggest difficulty in implementing these types of improvements will be coding it to be backwards compatible (although making this possible is presumably the entire reason why the version number is required in the wrapping tags to begin with).

[qgustavor]

The version number is more useful for cases like changing the used cypher or algorithm, not the formatting. But, the current format is really strict I think it makes it to support, there are fewer edge cases.

There are test cases, right? Use those to avoid any kind of regression. One way to make this more easy to implement would be restricting to the main points related to using it on paper: making it case insensitive and changing the base to one without similar characters.