[Feature Request] Support multiple websocket connections in nym-client

[parazyd]

Currently, nym-client only ever allows a single WebSocket connection at a time. This is far from convenient for any type of advanced use.

To implement this, it should be possible to detach a task for every TCP accept that happens in listener.rs. The code could then simply copy all messages it has to all active listeners so every websocket client can see the same messages that are being propagated.

This feature would allow multiple API clients to use the websockets API concurrently and would greatly improve developer experience and code performance when multiple active websocket connections are necessary.

[jstuczyn]

Hey! Can you elaborate a bit more about the "advanced use" you have in mind? Because it should be the case that a single application wanting to use the mixnet should connect to a single instance of a nym-client. They shouldn't really be sharing it.

[parazyd]

The case is implementing a client and a server using a familiar API in Rust. For example in the way you have TcpStream and TcpListener.

By allowing multiple websocket connections (and with multiple I mean that nym-client could simply send the same messages to all active websocket connections) it would then be possible to implement a good client-server architecture that uses AsyncRead and AsyncWrite and be able to use Nym transparently in any application that wants to use such a library. In turn, nym-client can also listen for all messages coming from websocket clients and handle them the same way it's handling them now. There is no need to actually differ between the websocket connections. Every client that connects should see the same messages and nym-client should handle all messages that it's seeing from clients as one.

I implement such a concept library so you can actually see how it is useful: https://github.com/parazyd/nym-dumpster/

[parazyd]

@jstuczyn Any feedback on this?

[jstuczyn]

Yes, sorry. I've been pondering about this one, and I'm not entirely convinced whether broadcasting received messages to all websocket connections would be the best idea. While it might work for your use case, other people might get extremely confused. Say somebody connected two different applications to the same underlying client, for example a chat client and a crypto wallet (because in principle there would be nothing preventing them from doing so). They'd probably expect to only receive relevant messages back - the chat might get confused if it received some transaction results.

So we'd most likely need to implement some form of multiplexing and message tagging to figure out what goes where. But that's most likely part of a bigger discussion.

[parazyd]

This can potentially be done by generating some kind of ID (or UUID) upon initial connection to nym-client, and then you tag that specific socket internally in nym-client, which will essentially become the router for websocket clients in that case. I think it can even be done without websocket clients actually having to care about it. Just as an abstraction over the websocket server, some kind of minimal router can be implemented based on the TCP sockets.

[octol]

To me it sounds like how it's done in nym-socks5-client with connection_id?

[parazyd]

Any news on this?