There has been discussion for years about how to make Syncthing’s discovery more resilient. DHT has always been the proposed solution. But this would be complex and heavy.
I think that using Nostr relays is a better solution. There are already p2p projects, like Hashtree, that use ephemeral events to discover peers.
This would be much simpler and would be pretty lightweight, while still decentralizing Syncthing’s discovery.
The real problem goes a bit deeper. Real p2p would also need to cover the initial connection between devices. But almost any kind of DHT requires extra cryptography. The only thing our clients know about each other is the device ID.
Correct. The handshake to form the p2p connection would be straightforward using nostr relays. Devices would just gossip their info to relays using ephemeral events.
A DHT hasn’t been implemented yet because it’s quite complex.
A simple “knock and callback” could be used so that no IP address is ever publicly exposed. And all of this could be done only knowing a device’s ID.
From a quick reading about Nostr and relays, it sounds like they are server instances just like our discovery servers that you’d need to run, and then specifically point your client to. Which is to say, they are conceptually shaped just like the current global discovery servers, just using a slightly different protocol?
Moving Syncthing discovery to a DHT would be primarily for two advantages as I see it:
Does Nostr help with that? (If we’d just rely on someone else to run the beefy servers and have to trust them instead, I’m not sure that’s a win.)
Is there any plans to have DHT in syncthing?
Sure. The question is how to do it without completely breaking how devices are initially connected with each other.
Exchanging the necessary public keys on an existing connection would be easy to do. But we’d still rely on central infrastructure for getting the first connection established.
All nostr relays do is store and broadcast JSON text. The nostr protocol is simply a standardized way of doing it so that an entire open public infrastructure can be built.
There are thousands of relays on the network since anyone can run one. So you technically wouldn’t have to run any infrastructure yourself unless you wanted to.
If syncthing used nostr, then a user could simply add a bunch of public nostr relays to a list in the settings. There could also be a couple hardcoded relays that you operate yourself, if you wanted.
So maybe what we’d actually be doing is learning to “speak nostr” so that we can utilize the huge network of public relays.
Down the road you could be clever and implement a way for devices to gossip and inform each other of other relays that they know about. Something akin to (or precisely) NIP-65.
I think bootstrapping is an issue with any protocol you go with, even DHT. However, at least with nostr there’s thousands of public relays in the network already. You can operate anywhere along the continuum between centralized and decentralized.
Only use a couple “official” syncthing ones: centralized.
Have a list of a hundred public ones: pretty decentralized.
It’s a very lightweight protocol, so it doesn’t stress the system/device or require heavy infrastructure. Current nostr clients on phones typically use around 10 relays at once to pull data and make a social feed.
I should clarify though. A DHT would be ideal. But Nostr would be a simple and lightweight way to tap into a large, distrubuted, public network for peer discovery.
Help me understand how that would work. My understanding (from five minutes on the nostr web, so could be wrong) is relays don’t talk to each other. Is the idea that we have a list of a hundred relays, announce to all of them, and query them all until we get a hit?