signpost[asciilifeform]: asciilifeform: yep, the fountain code gives us an expected overhead above the requested file's size. a final version oughta stop there on both sides.

signpost[asciilifeform]: current item's a pretty rough proof-of-concept

signpost[asciilifeform]: e.g. does not detect loss whatsoever

signpost[asciilifeform]: in the current rough prototype the receiver has a sense of what blocks it needs to resolve, but does not have a per-block way to know whether a block it thinks it has resolved is valid. the fountain code's check blocks are 384 bytes (comes from what fits inside the pest packet). they've got a randomly generated ID that's u

signpost[asciilifeform]: sed as a seed to retrieve the edges of that check block.

signpost[asciilifeform]: https://pdos.csail.mit.edu/~petar/papers/maymounkov-online.pdf << paper

signpost[asciilifeform]: there are conceivably ways to carry along some sort of checksum, breaking large files into smaller streams (each with its own checkable hash), etc

signpost[asciilifeform]: you have two encodings here. one spreads the impact of loss (the check-block "inner encode") and the other facilitates recovery (the aux blocks "outer encode")

signpost[asciilifeform]: maybe there's a scheme where the handful of "useless" blocks we get which resolve to message blocks we already have could be used to bail out early if they disagree with what we have.

signpost[asciilifeform]: somebody's a liar in that scenario

signpost[asciilifeform] will write up the scheme properly when it solidifies too. I don't intend coad to be a spec.