1-n broadcast

[cwgoes]

Should work both on ordered & unordered channels.

This will need to alter the handshakes.

[cwgoes]

Difference between "UDP multicast" (no knowledge of receiver) and "receiver-known" broadcast.

The former should not require handshakes, the latter will.

Subscriptions mechanisms will likely require the latter (known receivers).

[cwgoes]

Maybe best for "IBC 1.1".

[cwgoes]

However, we should ensure that this can be added in a backwards-compatible way.

[zmanian]

Microtick is also interested in 1 to N channels.

[mconcat]

I believe the former can be specified as a backward-compatible way

• Opening: sender designates the set of receivers, run handshake with each of them, establish channels with (successful parties / all or not, depending on the settings).
• During broadcast: sender pushes packets to the channel, cleanup will check all of the receiver chains
• Closing: either sender closes the channel, or (all / one of, depending on the setting) receiver chains close the channel.

we need to define a way to abstract a set of channels into a single channel in this case, but we can reuse the logic.

For the latter, we need to define a new channel type, with single-sided opening/closing and time-based cleanup.

[cwgoes]

By the former, you mean "receiver-known" broadcast, right, since the sender designates the receiver set?

Even with "receiver-known" broadcast I think we should allow the receiver set to change after the channel has been opened.