Persist IDs and port numbers between restarts

[feross]

Things that can be persisted between restarts:

• torrent client peer ID
• torrent client listen port
• dht node ID
• dht port

The DHT needs to be persisted (#72), and that means our DHT node ID shouldn't change between different runs of the webtorrent program.

Persisting the torrent client listen port and node ID might get us more peers (if we're still listed trackers and DHTs). Should we persist the torrent client peer ID too?

Are there privacy implications to re-using the peer ID? What does Transmission do?

[Wingman4l7]

Definitely persist at least the peer ID prefix, or you won't be able to have webtorrent be a whitelisted client on private torrent trackers!

[feross]

Yep, we have a consistent prefix! It's -WW.

[Wingman4l7]

I thought so! I might suggest that you append the version number of webtorrent to the prefix, so that a specific stable version of the client can be whitelisted.

[feross]

Yep, we already do that. You can see the code here: https://github.com/feross/webtorrent/blob/5f3e73f9937228fac0b9974de7db5b4fbb16b1bf/index.js#L61

[Wingman4l7]

... I think I knew that. >.< Well, great! :D

[gillesdemey]

Transmission persists at least a part of the peerid, like -TR1330- and the rest of the 20 bytes are filled in at random, just like WebTorrent does it right now.

https://trac.transmissionbt.com/wiki/PeerId

They generate a new peerID every six hours though, see https://trac.transmissionbt.com/changeset/13933

[feross]

@gillesdemey

That part of the Transmission ID (-TR1330-) identifies the client and the version. For example, WebTorrent uses -WW-0057.

Interesting that they generate a new ID every six hours. Perhaps that's to prevent long-term user tracking?

In any case, it looks like there's probably no benefit (and possibly privacy harm) to preserving the peer ID over the long term. Good to know.