Existing fountain encoder cannot create suitable fountain frames from "big" messages

[ananondev]

It appears that in this implementation, k is recovered directly from "fountain frame" header sections which also allocate memory for a mapping of data frame idcs which could be recovered algorithmically. When dataChunks.length is large enough, exporter makeLoop will produce a fountain frame that cannot actually fit within a QR code (for which a length check + throw could be added here). I don't know what the upper message size limit is but it's not so high for a datasize of 120. Content sizes too big for QR codes cause QR code generation to throw.

Other encoder implementations of Luby transform coding appear to make k recoverable without even producing 'fountain' vs 'data' frames, storing msg and chunk size on the messages themselves.