Closed dmgolembiowski closed 3 years ago
Please check out #109 and #66. Where does your proposal differ from those issues? Could it be implemented on top of those issues? Or could those issues be adapted to better fit your use case?
Please check out #109 and #66. Where does your proposal differ from those issues? Could it be implemented on top of those issues? Or could those issues be adapted to better fit your use case?
Very interesting; thank you for sharing, @piegamesde. I'm excited that others have the same goals and ideas. My apologies for being so tunnel-visioned and failing to see the issue #109.
This is a split from issue #66 because while the implementation might be similar, the UX concepts and use cases behind both are quite different.
I'm thinking of something like running
wormhole tunnel $PORT
on both sides and if the handshake succeeds,localhost:port
of one machine is transparently connected tolocalhost:port
of the other machine. Probably TCP only.
TCP feels like the way to go on the SSH use-case. Nobody's going to be typing at the speeds necessary for other protocols. But out of curiosity, how substantial would it be to tackle both TCP and UDP?
But out of curiosity, how substantial would it be to tackle both TCP and UDP?
Basically no. You can tunnel UDP over TCP if that makes you happy (I doubt it will though).
I'm going to close this as duplicate of the others.
Hi all,
I'm glad to meet everyone here! There's a feature I want to implement over at magic-wormhole/magic-wormhole that others here might want to weigh in on. If I were to build the lower-level communications in this repository, do I risk sullying your work or crate dependencies? If so, what could I do to stay out of your way but still accomplish this feature?