Currently we the maximal size of the QR code limits the maximal size of allowed text rather heavily.
There are two ways this can be improved:
a) it makes sense to compress the original text -- and compression should work efficiently enough on both natural text and ascii-based serializations like armored GPG exports.
b) the actual way of recording the shard into QR code might need tweaking -- since used QR alphabet (see here) and shard's serialization mode should allow better storage efficiency.
It goes without saying that BananaSplit should retain backwards compatibility indefinitely, so in addition to this new serialization format all previous ones should be supported as well.
Currently we the maximal size of the QR code limits the maximal size of allowed text rather heavily.
There are two ways this can be improved:
a) it makes sense to compress the original text -- and compression should work efficiently enough on both natural text and ascii-based serializations like armored GPG exports.
b) the actual way of recording the shard into QR code might need tweaking -- since used QR alphabet (see here) and shard's serialization mode should allow better storage efficiency.
It goes without saying that BananaSplit should retain backwards compatibility indefinitely, so in addition to this new serialization format all previous ones should be supported as well.