Feat: BitTorrent v2 Support [BEP 52]

[leoherzog]

What is the purpose of this pull request? (put an "X" next to item)

[ ] Documentation update
[ ] Bug fix
[ X ] New feature
[ ] Other, please explain:

What changes did you make? (Give an overview)

Added parsing of infoHash and/or infoHashv2, as well as generation of v1, v2, or Hybrid torrents.

Which issue (if any) does this pull request address?

Issue #88

[sneakers-the-rat]

Thanks for getting to this so quick, my week filled up faster than in anticipated. We will probably need to follow this up with some convenience methods for getting piece roots and piece layers at file offsets when working on the downstream webtorrent impl, but it looks like most of the parts we need are in place here, modulo open comments

[leoherzog]

@ThaUnknown @sneakers-the-rat Incorporated your feedback and made a bunch of tweaks. Can rebase/squash before merging, if you'd like.

[leoherzog]

@ThaUnknown @sneakers-the-rat Awaiting feedback

[ThaUnknown]

I'm aware I'm holding this back, the PR itself for the most part looks fine, but I don't know about the functionality, since I'd need to go into the specifics of btv2, read the spec, and test it myself, for which I don't have time as of now

[leoherzog]

@ThaUnknown Cool. Let me know if I can be helpful in that somehow.

https://blog.libtorrent.org/2020/09/bittorrent-v2/

[sneakers-the-rat]

Sorry dropped off my radar. I know the spec and have written a parser and generator so can evaluate. Marking unread to check out tmrw

[sneakers-the-rat]

ok cool, this is much smaller than i thought it would be - this pretty much covers it if the goal is just to load it into a js object rather than validating.

can't really comment on compatibility with downstream use, but flatting the file tree is sort of the main thing, and downstream consumers will have to figure out how to deal with the absence of v1 pieces and validate with the file trees instead.

one thing that might be useful is to have an additional version field that is "v1" | "v2" | "hybrid" so that downstream consumers can check that without needing to repeat the sort of awkward checks for presence of different fields

[leoherzog]

Thanks for looking at this, @sneakers-the-rat. I really appreciate your time and thoughts.

I think I've addressed all of the raised points. It's a lot cleaner now. Again, I'll leave the commits all separate for clarity in this PR for now, but I can merge/squash into a couple of clearer commits when we think everything's resolved.

Also, I'm not sure if it's you maintainers' job to "resolve conversation" on the comment threads, or mine :)

[sneakers-the-rat]

(fwiw for maintainers, all my comments addressed :)

[parthibx24]

why is this stale 😭

[leoherzog]

@ThaUnknown I have "resolved" all of the open comments from @sneakers-the-rat

[ThaUnknown]

yes but webtorrent is dead until @feross fixes the NPM keys that have expired, so this won't be published until that's done anyways

my general lack of interest, or deep understanding of the protocol doesnt help, neither does the utter hatered for how horrificly this package is structured and written

[sneakers-the-rat]

so where does that leave us? surely it can't take too much time for @feross to fix the keys right? this little bitty thing is just the first step in v2 support, so should we take this as a sign not to bother and treat webtorrent as abandoned? or do we merge this and continue even if we have feeling about the code structure?