@joepie91
hyperdht makes eclipse attacks hard if thats what you mean how surveillance bodes would work.

you also have blind relays

https://github.com/holepunchto/blind-relay
https://github.com/holepunchto/blind-pairing
https://github.com/holepunchto/blind-pairing-core

this is the dht:
https://github.com/holepunchto/hyperdht
https://github.com/holepunchto/hyperswarm-dht-relay

@serapath Not quite talking about eclipse attacks; rather just old-fashioned "try to be the chosen relay node to map out connections of other parties".

Is there a security design document for HyperDHT?

@joepie91 aadly it is all in the source.

the way you get assigned in the DHT is by hashing your IP address and then the existing network challenging you to proof you have that IP address and only then you get the spot.

I am not sure what kind of attack toy mean otherwise. There is sadly no design document.
The source code is the spec.

Its not ideal, but without VC funding and without massive government funding... that is how dat had to household.

Also, when things change its more effort

@joepie91 apaet from that. the community around it knows how things work and answer questions.

the development mostly gappens on the keet messenger these days, which itself runs on hyperdht and the entire dat stack or pear runtime

@serapath Without a security design document, it won't be suitable for what I'm trying to do (which is the same reason I've discarded a lot of other options - I want to see exactly what security considerations they have made and how they ended up at their design choices)

@joepie91 i see.
it might exist in the future.

the code is very readable and basically executable spec.

but i understand.
too bad. anyway - am curious with what you figure out and what options you find.

I follow for so many years and know many of the people working on it that i am kinda familiar with many aspects, but yeah - a comprehensive up to date design document does not exist as far as i know... sadly

@serapath Note that a security design document and a spec are not the same kind of thing; a spec tells me what to implement or how, and a design document tells me *why* it is meant to be implemented that way, and that's really important information for security analysis (and code comments are basically never detailed enough, they are missing high-level architecture)

@serapath (RFCs usually include both but I've pretty much only ever seen RFCs and some XEPs do that, not any other specs)