Just reading the description, I guessed it would be a fountain code. And, indeed, it’s a very very thin wrapper around RaptorQ. So it gets data through a link that drops each packet, independently, with moderate probability, at approximately the maximum rate in the sense of number of packets transmitted divided by total message size.
What it does _not_ do is anything resembling intelligent determination of appropriate bandwidth, let alone real congestion control. And it does not obviously handle the part that fountain codes don’t give for free: a way to stream out data that the sender wasn’t aware of from the very beginning.
It seems to me that there are exchanges between the client and the server. So it wouldn't be usable in its current state with a network diode.
Network diodes have very low packet loss rates, for the simplest ones they are literally fibre to ethernet transducers with a disconnected channel and a few centimetres of fibre. There is no external disturbance that could generate significant bit flip.
The more complex diodes use multiple transducers, power supply, fibres for redundancy and protocols to detect when one of the channels is out of order.
The diode manufacturers don't give details but we're probably looking at rather simple error detection and parity codes that can be easily implemented on an ASIC or FPGA to obtain high data rates.
On top of this you can use unidirectional protocols in UDP. But the diode works mainly at the physical and data layers of the OSI model.
Some diode manufacturers include proxies to simulate an FTP server and make it easier for users who just want to retrieve logs from critical infrastructure.
What it does _not_ do is anything resembling intelligent determination of appropriate bandwidth, let alone real congestion control. And it does not obviously handle the part that fountain codes don’t give for free: a way to stream out data that the sender wasn’t aware of from the very beginning.