Open michele-nuzzi opened 1 year ago
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 120 days.
We think the best approach is to build such a proxy as a separate binary as otherwise it would increase security risk and maintenance costs.
It's not something difficult to do, but the design will depend on how one wants to embed the node-to-node
protocol into WebSocket frames. One approach would be to simply wrap Handshake
messages and mux
SDUs in a websocket frames, but maybe that's not the only option.
To be clear, the security risk is the increased footprint of the libraries that would be part of the node. We have an ongoing strategy to remove as many of these as reasonable. In particular we are trying to eliminate the need for HTTP related ones from the package footprint.
That makes sense, thanks a lot for the explanations
To be clear, the security risk is the increased footprint of the libraries that would be part of the node
This could be covered with package compile flag.
Projects who need WS will still have such dependencies and thus "package footprint", just from separate project. Thus Cardano infra would get one more reason for differentiation, and thus more work by downstream projects and more security risks.
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 120 days.
Related issue IntersectMBO/ouroboros-network#4908.
Internal/External External
Area Other
Describe the feature you'd like
It would be great if the node could listen to WebSocket connections on top of TCP ones.
The main reason for such a feature is light clients; which would then be able to participate directly in the network from the application using them.
Describe alternatives you've considered
Having a proxy that translates WebSocket requests to TCP socket ones; not the best if we want to keep it trustless.