search

pubky / pkarr

Public Key Addressable Resource Records (sovereign TLDs)
https://app.pkarr.org
MIT License
153 stars 17 forks source link

support configuring bootstrap nodes / bootstrapping the dht #48

Closed dvc94ch closed 6 months ago

dvc94ch commented 6 months ago

yeah, looks like docker is just buggy on mac. tcp works fine, udp not (can't open outgoing udp connections with host using netcat, but can receive incoming connections). will look into bootstrapping the dht tomorrow, so we can keep everything inside of docker image

Nuhvi commented 6 months ago

@dvc94ch by "keep everything inside of docker" you mean for testing and CI? I can publish a version that accepts a Mainline instance for now until v2 is ready. But if you want to interop with the outside world maybe consider Docker like browsers (or Replit) and use a public relay?

dvc94ch commented 6 months ago

it's for testing locally, since most of our devs use a mac. ci runs on linux which doesn't cause any issues and deployment is on a k8s cluster which also doesn't cause any trouble.

dvc94ch commented 6 months ago

that being said, is there any advantage to using bittorrent instead of bootstrapping our own dht? seems like us filling the bittorrent nodes with records or our nodes getting filled with bittorrent records doesn't help either party.

Nuhvi commented 6 months ago

@dvc94ch depends on what you want from a DHT, if you want censorship resistance, then you should seek the biggest set of routers with the most track record of weathering coordinated well-funded attacks.

And if you do run a proper router Mainline does benefit (marginally because they already have millions of nodes already) and you benefit immensely because the alternative is probably a DHT of a handful of nodes belonging to even fewer entities.

That being said, my Mainline implementation isn't a proper router yet (doesn't store records) so using it for testing isn't going to work, I need to remedy that.

Nuhvi commented 6 months ago

@dvc94ch forgot to mention, that the only way to have separate networks is to break compatibility with FindNode messages and the routing table, for example using sha256, because otherwise, networks can accidentally merge as it happened before. All it takes is one node that adds nodes from both networks, and they will merge in no time, even if nothing else other than the routing table and FindNode request/response is compatible.