From my understanding of the IPNS subsystem, every IPFS node has at least one IPNS private key that they maintain (“self”), which then the public key related to it becomes their Peer ID. But each node can create more private keys to use as IPNS names, if they wish. IPNS keys can create “IPNS records” that are signed messages pointing to something (a CID or another IPNS). The IPNS records get circulated around the IPFS peer network (any IPFS node can keep local caches of the IPNS record, same as they keep local caches of data associated with specific CIDs). Is that much correct?
My question then is how private/anonymous are IPNS names? I believe the IPNS keys that are a peer’s ID are very closely bound to that specific node’s IP address, so are not very anonymous. But if an IPFS node creates a new IPNS private key and uses it to publish an IPNS record, is that able to be tracked back to which IPFS peer node is the publisher?
About none.
You don’t need to use the same key as your peerid, you can generate new keys with ipfs key but the DHT is not resistant.
If someone would like to know who is publishing some key they can bruteforce peerids to be part of the 20 peers keyspace which will handle the ipns name, then they run a node and next time you do a publish you will contact them.
You could make that better with tor but we don’t have that in Kubo rn due to the extra hardening required.
Oh, that was something I didn’t realize about IPFS’ distribution strategy: for “Provider Records” (CID-to-data links) and IPNS records, when published they target a specific number of other peers to also host the content (20). That’s different from a Torrent distribution, where there can be many, many “seeders” for a specific bit of content who are all voluntary). Thanks!
Torrent does the exact same thing, we don’t put files in the DHT, you can have many seeders just like torrent.
The DHT is a map of CID → [PeerIDs], similar to the torrent DHT. It only stores the list of nodes which have the file.
IPNS records are short so we do store them directly in the DHT but you technically don’t need to do it, it’s the only exchange method available in Kubo right now (*we do support exposing them over HTTP API for light clients but Kubo wont ingest it that way only expose).
If you don’t use the torrent DHT then you are using trackers, which is similar to IPNI (https://cid.contact/), sadly we don’t yet embed trackers as query parameters of the URL yet, so you can’t easily switch your trackers and mostly rely on the dht (where torrent do the inverse, trackers are the most used solution and dht is a backup).