@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
@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)
@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