Relay/multicast fan-out for large-N broadcast + large group video (streaming scale, 1.x)

[emooreatx]

Relay / multicast fan-out for large-N broadcast + large group video (streaming scale)

The realtime A/V mesh (#54/#62) covers small/medium rooms via direct Reticulum Links. The PQC streaming bandwidth model (CIRISRegistry FSD/CEG/pdf/) showed the decisive open question: the TreeKEM rekey advantage (O(log N)) and large-audience content fan-out both require efficient multicast — over a pure unicast mesh, the tree is O(N log N) (worse than flat) and content fan-out is the dominant bandwidth cost.

Scope (explicitly 1.x per CEG §10.5.5 E2 / §10.5.8)

• A relay / SFU role: selective-forwarding fan-out for (a) large-N 1:N broadcast and (b) group video rooms beyond ~50 participants.
• Multicast-style aggregation so a TreeKEM commit (O(log N)) is sent once, not N times.
• Two-layer crypto preserved (§10.5.5 E1): relay never sees plaintext (transit-key under the E2E epoch DEK).
• Measure first: run rns_transport_bench.py (CIRISRegistry FSD/CEG/pdf/) to quantify whether/where native RET multicast exists before building the relay.

Status

1.x, not 1.0-blocking (CEG 1.0 ships pull-only broadcast + small-N realtime mesh). Filed so the scale lever is tracked, not a silent gap. The model's free parameter (RNS Link RTT/throughput/multicast availability) is the input that decides the design.

Refs: CEG §10.5.5/§10.5.8, CIRISRegistry#57 (1.0 readiness), the bandwidth model + rns_transport_bench harness.