True reliable message delivery over a Livekit WebRTC data channel using Javascript?

Question

The LiveKit documentation has this note regarding publishing data over the 'Reliable' WebRTC data channel:

note

Reliable delivery indicates "best-effort" delivery. It cannot fully guarantee the message will be delivered in all cases. For instance, a receiver that is temporarily disconnected at the moment the message is sent will not receive it. Messages are not buffered on the server and only a limited number of retransmissions are attempted.

Having missing or unordered messages can throw a loop in my application logic. For example: chunked file transfers & implementing higher level handshakes over the data channel.

I've naively tried to fix this by incrementing a counter on the sending and receiving peers, and sending that counter along with each message over the data channel. When an incoming message skips ahead of the receiver's counter, the receiver will queue messages until the missing one(s) come in. That works great assuming messages never get lost! Of course, they do get lost without warning when one peer or the other changes wifi networks or cell towers or reloads the webpage! Using message acknowledgements would work here, but properly implementing ACKs to minimize edge cases and bandwidth congestion is not straightforward.

I know there are many protocols out there that solve this problem and took years to get right like MQTT, ZeroMQ, TCP, & QUIC. However, I couldn't find a library or protocol that has support for web browsers without a backend over arbitrary transports like Livekit WebRTC data channels.

Q: Does such a Javascript library exist? If not, what is the best approach to implement this and what are the gotchas that this approach avoids or that I need to handle?

Simplifying assumptions I can make:

1. Each message is only going between two participants with defined roles (there may be more participants in the room but each message exchange is one-on-one. No 'broadcast' type messages).
2. Both participants are using web browsers and the Livekit Client JS SDK.
3. Both participants were connected to the same Livekit room and are briefly disconnected for a few seconds.
4. Messages do not need to be persisted and re-sent if one peer or the other closes their web browser or reloads the page
   1. However! This shouldn't prevent new messages from flowing if the same participant re-joins in a few seconds!
   2. Ideally, I should be able to detect a participant who has permanently left / will never receive messages and update state accordingly.
5. It seems like ordering of messages is actually guaranteed by Livekit now - I made a Test Code Sandbox to check that.

Other things I've thought about:

1. Do I need to worry about WebRTC buffers and congestion control? - Perhaps the Livekit event DCBufferStatusChanged is useful here.