Idempotent decode and encode

[daviddias]

Hi @feross!

I'm trying to make the encode and decoding of torrent files idempotent. It makes it extremely useful when linking to torrent files by CID/multihash, so that at least we don't generate new torrent file versions in memory while manipulating them.

Right now, I'm 5 bytes down from the original:

# encode
634 639
not ok 9 should be equivalent
  ---
    operator: deepEqual
    expected: |-
      <Buffer 64 31 30 3a 63 72 65 61 74 65 64 20 62 79 31 33 3a 75 54 6f 72 72 65 6e 74 2f 33 33 30 30 31 33 3a 63 72 65 61 74 69 6f 6e 20 64 61 74 65 69 31 33 37 ... >
    actual: |-
      <Buffer 64 31 30 3a 63 72 65 61 74 65 64 20 62 79 31 33 3a 75 54 6f 72 72 65 6e 74 2f 33 33 30 30 31 33 3a 63 72 65 61 74 69 6f 6e 20 64 61 74 65 69 31 33 37 ... >
    at: Test.<anonymous> (/Users/koruza/code/parse-torrent-file/test/encode.js:12:5)
  ...

Could you help me figure out these last 5 bytes?

I understand that there is no requirement for this by the bittorrent spec and it might even be impossible to ensure that is always idempotent. If this turns out to be the case, I'll just have to cope with it :)

Thank you!

[feross]

I think the issue is that when decoding a torrent file, we throw away the keys that we don't understand. So in this example, the torrent has a key "encoding": "UTF-8" that is getting discarded by parseTorrentFile.decode since it's non-standard and not understood by this package.

One possible fix would be to include all unknown keys so they can be used in parseTorrentFile.encode. But I wonder if you should be relying on these objects being the same anyway. The only reliable way to refer to a torrent is the "info hash". Something to consider.

[feross]

@diasdavid If I understand correctly from the other discussion, you're just planning to use the info hash to describe the torrents? So I believe this PR can be closed?

[daviddias]

@diasdavid If I understand correctly from the other discussion, you're just planning to use the info hash to describe the torrents? So I believe this PR can be closed?

I'll use both, but favouring the infoHash as that is going to be the only piece that will have integrity.

But I wonder if you should be relying on these objects being the same anyway. The only reliable way to refer to a torrent is the "info hash". Something to consider.

True, It is unfortunate, though. I would still like to be able to read and write Torrent files to disk and preserve their hash when I don't make changes to them.

I'll think more about this and come back to this PR if needed. Thanks!

[feross]

It would be possible to make this library pass through the keys it doesn't know about. The PR just needs a bit of work to make that happen :)

[daviddias]

Understood :) Will come back to propose those changes too as soon as I can!