Skip to content

F2.5 - Fountain codes for broadcast / HF / multi-path #138

Description

@M0LTE

Idea

A fountain code (LT, Raptor) lets the originator emit an unbounded stream of random-combination packets; any recipient who collects K(1+ε) of them reconstructs the source. No back-channel retransmission protocol; the sender just keeps emitting and recipients tune in until they've collected enough.

Where this shines is the corner DAPPS is most under-served on today: HF broadcast and multi-path mesh delivery on lossy / asymmetric links. A bulletin-style "broadcast a digest, any of N listening nodes builds it up over a propagation pass" feature is the natural home - completely different transport profile from F2's acknowledged unicast resumability.

Why not now

  • DAPPSv1 is acknowledged point-to-point (ihave → send → data → ack); fountain codes' natural home is unacknowledged broadcast - the wrong primitive to retrofit.
  • Decoder is 500+ lines we'd own forever; LT is tractable on a Pi, Raptor is faster but the patent situation is murky.
  • We don't yet have the broadcast shape (B6.2 HF solicit is on-demand request/reply; nothing today is multicast-mesh-shaped).

Where it'd land

Alongside a real broadcast surface - e.g. "DAPPS bulletin" one-to-many, no-ack, fountain-coded over HF - as its own transport profile coexisting with F2's classic chunking. F2's frag=N/M doesn't preclude this; they're different shapes for different jobs.

Adjacent

Same library/decoder is also relevant for #136 (B8 collaborative route gossip), where the broadcast-route-table case has the same shape.

Migrated from plan.md Phase F2.5 (future option, not in F2's scope).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions