Application-layer library

[RainaBatwing]

There are some great ideas in this project, but like previous attempts to build a system level virtual network, snow has a platform problem: Nobody wants to spend a lot of effort building apps for a platform nobody has installed, and nobody wants to install a system level platform that has no or very few good apps, especially if it's likely to consume background resources running systems like DHTs.

ZeroTier and earlier versions of Telehash suffered from this problem, and neither have been significantly adopted.

One way to improve this is to build an application-layer version, where each application has a public key endpoint and runs it's own node in the DHT. Designing like this eliminates the need to mess with system-level routing or DNS resolution, and provides increased privacy by giving each application it's own address.

If our users have to install some weird system thing that might mess up their DNS if it's buggy, that's a huge barrier.

[rektide]

The DHT appears integral to the functionality- it's how keys are looked up.

If you don't want to participate on the known DHT, don't want resources going to other people, then don't use the known_peers- use your own peers, and don't tell anyone else.

If it were just a manner of resolving an IP (which is what the DHT is for), exposing Snow as a library would make sense to me. But seeing as how Snow is overlay networking, the complexity of implementing a consumable API is quite high- Snow would be trying to expose it's own reimplementation of socket. There's not a lot of good existing work to stand on for doing that, not a lot of best practices for that. TUN/TAP is far more conventional and normative an approach here, with a lot of great guidance and experience, and it's very high performance. Running it as a separate application & using TUN/TAP ought provide no significant change in background resources versus trying to embed it as a library, if you accept that it's going to need to be DHT'ing anyways (to resolve keys).

[zrm]

Nobody wants to spend a lot of effort building apps for a platform nobody has installed, and nobody wants to install a system level platform that has no or very few good apps

It is possible to write apps that specifically assume the ability to resolve key names but snow is also useful with existing apps. It can add NAT traversal and authentication to anything that resolves names and sends packets.

Having each application operate its own instance of the DHT would at best only leave resource consumption unchanged (one application and one instance of the DHT) and as soon as you had a second application it would only make it worse, although the resource consumption of the DHT is modest anyway.

You can already operate the daemon without changing the system DNS server. Applications that specifically want to resolve key names can then direct their queries to localhost while other applications continue to use the existing system DNS server.

The privacy effect of using multiple keys on the same host is arguably negative. If they all share the same "real" IP address then they can still be correlated but it would allow an observer to more easily tell which traffic originates from which application. Although there is also no reason you can't run multiple instances of the daemon each with its own key if some justification can be found for it.

That isn't to say a library as an alternative interface to the daemon couldn't be useful.