I hadn’t thought about that, but I would think it is possible.
You could create a web-socket custom element for the server communication. A con would be that you need to store the queue of all outgoing messages in elm and also have to drain the queue using events from the element. Similar to the two-way handshake of tcp. A pro would be that we could handle failing or rejected messages.
Adding ICE candidates and SDP using attributes should work well, right now the user element is always rendered anyway. But then the custom element would own the peer connection state (and storing it in Elm too would not make sense). Definitely makes sense for a reliable solution, but I wanted Elm to hold all state in this example.