3 ms·

Very good summary, and thanks for bringing up the license distinction, the noisysockets core library will always be MPL-2.0 and open to the community. The fund

Very good summary, and thanks for bringing up the license distinction, the noisysockets core library will always be MPL-2.0 and open to the community. The fundamental thesis behind noisy sockets is, "What if your network endpoints were processes instead of machines?" And as you say bypassing the host networking stack actually brings a lot of benefits (eg. avoiding those VPN leak shenanigans), it's actually interesting when you squint enough it begins to even look vaguely something like QUIC (in that you have multiple encapsulated streams/channels/sockets going over UDP with their own congestion control). Peer discovery and NAT traversal are next on my list. I'm going to implement a kind of userspace lighthouse peer that will advertise peer endpoints to the network. I'm still trying to think about how I will deal with TURN/DERP. I suspect I'll tunnel WireGuard over WebSockets and just have each peer listen on UDP/TCP. Maybe one day that will allow even an in browser peer with WASM (which I'm sure someone will find an interesting use case for). Also on the list is fine grained authentication/authorization (interestingly netstack has an iptables implementation), some of it will be opensource and some of it will be source available (sorry for the SSO tax).

0xbadcafebee 2y ago
I feel like you're very close to an implementation which would finally break the HTTP hegemony on network protocols. I would strongly suggest looking at non-Web methods (I haven't done much research into TURN/DERP so I can't suggest anything specific) I would also suggest looking at ZeroMQ if you haven't yet; their design & implementation is really fantastic. They implement the bare bones in the library, and then you can go implement your own components with it for whatever architectural topology you want. So for example, you could make a closed-source paid product of a connection broker using the library, and somebody else could make one for free as open-source. Both have their use-cases, and they're both compatible with all the other apps in the ecosystem. This benefits you as it legitimizes the product and grows the ecosystem, and encourages more use due to its flexibility
- dpeckett 2y ago
  Thanks for the kind words and great suggestions, I'll take a very close look into ZeroMQ, I'm also keeping an eye on NATS. Some kind of paid connection broker / app platform actually sounds like a solid way to build a sustainable business out of something like this. I'm trying to avoid the tailscale model of having to lock up the control plane.
  - 0xbadcafebee 2y ago
    I agree it could be a viable business model, but the trick seems finding a market. Since QUIC exists, most people (including virtually all client-side apps) will just use that. But QUIC is still TLS and HTTP, which is unnecessary for a lot of use cases and adds complexity. I think if you created developer-friendly tooling/libraries/servers/etc that were dead-stupid-simple, people would use that over TLS/HTTP, for anything other than a web browser. Android apps and tunneling applications might use it on the client side, and MQTT would be a great use case on the backend. The one thing I think would be a stumbling block to the simplicity is the use of public keys. It's just super clunky compared to basic username/password or PSK auth. I don't have any suggestions here, I know Wireguard is pretty much wedded to public keys, but anything you can do to eliminate the many problems/limitations with public keys would help drive adoption. I think you can lock up the control plane if you want for an implementation, but keep the interfaces loosely coupled and part of an open standard with the library having simple hooks for everything. That way those that have some money and just need a fix now, will pay for your thing, and those that can't will write their own implementation and grow the ecosystem which you can then market off of. Like, Terraform could have been a closed-source tool, but the fact that anyone can write a provider means Hashi didn't have to write them all, and as more providers and modules were written, the tool cemented itself ever more as indispensable. (Which pisses me the hell off because Terraform sucks so bad, but it was a good business strategy heh) Last thought: I would also quietly advertise the library as as "TCP evolved" or something similar, because that's how I see this. Assuming you deal with NAT, I would absolutely use a protocol like this over TCP by default for all my applications. QUIC was almost there but the TLS and HTTP is so unnecessary for 99% of applications.
  - billywhizz 2y ago
    congrats on the release - it sounds like this will be very useful. can you explain what you mean by "having to lock up the control plane" here?
apitman 2y ago
> I'm working on a simple protocol capable of tunneling TCP/UDP over WebSockets. Basically you can think of it as a way of providing QUIC/WebTransport functionality over WebSockets (multiple streams, backpressure, datagrams, etc). Reference implementation is in Go. Feel free to reach out if it might be useful.

0xbadcafebee 2y ago

I feel like you're very close to an implementation which would finally break the HTTP hegemony on network protocols. I would strongly suggest looking at non-Web methods (I haven't done much research into TURN/DERP so I can't suggest anything specific) I would also suggest looking at ZeroMQ if you haven't yet; their design & implementation is really fantastic. They implement the bare bones in the library, and then you can go implement your own components with it for whatever architectural topology you want. So for example, you could make a closed-source paid product of a connection broker using the library, and somebody else could make one for free as open-source. Both have their use-cases, and they're both compatible with all the other apps in the ecosystem. This benefits you as it legitimizes the product and grows the ecosystem, and encourages more use due to its flexibility

dpeckett 2y ago
Thanks for the kind words and great suggestions, I'll take a very close look into ZeroMQ, I'm also keeping an eye on NATS. Some kind of paid connection broker / app platform actually sounds like a solid way to build a sustainable business out of something like this. I'm trying to avoid the tailscale model of having to lock up the control plane.
- 0xbadcafebee 2y ago
  I agree it could be a viable business model, but the trick seems finding a market. Since QUIC exists, most people (including virtually all client-side apps) will just use that. But QUIC is still TLS and HTTP, which is unnecessary for a lot of use cases and adds complexity. I think if you created developer-friendly tooling/libraries/servers/etc that were dead-stupid-simple, people would use that over TLS/HTTP, for anything other than a web browser. Android apps and tunneling applications might use it on the client side, and MQTT would be a great use case on the backend. The one thing I think would be a stumbling block to the simplicity is the use of public keys. It's just super clunky compared to basic username/password or PSK auth. I don't have any suggestions here, I know Wireguard is pretty much wedded to public keys, but anything you can do to eliminate the many problems/limitations with public keys would help drive adoption. I think you can lock up the control plane if you want for an implementation, but keep the interfaces loosely coupled and part of an open standard with the library having simple hooks for everything. That way those that have some money and just need a fix now, will pay for your thing, and those that can't will write their own implementation and grow the ecosystem which you can then market off of. Like, Terraform could have been a closed-source tool, but the fact that anyone can write a provider means Hashi didn't have to write them all, and as more providers and modules were written, the tool cemented itself ever more as indispensable. (Which pisses me the hell off because Terraform sucks so bad, but it was a good business strategy heh) Last thought: I would also quietly advertise the library as as "TCP evolved" or something similar, because that's how I see this. Assuming you deal with NAT, I would absolutely use a protocol like this over TCP by default for all my applications. QUIC was almost there but the TLS and HTTP is so unnecessary for 99% of applications.
- billywhizz 2y ago
  congrats on the release - it sounds like this will be very useful. can you explain what you mean by "having to lock up the control plane" here?

apitman 2y ago

> I'm working on a simple protocol capable of tunneling TCP/UDP over WebSockets. Basically you can think of it as a way of providing QUIC/WebTransport functionality over WebSockets (multiple streams, backpressure, datagrams, etc). Reference implementation is in Go. Feel free to reach out if it might be useful.