Antonio Pauletich

We settled on (b) option from https://github.com/bittorrent/bittorrent.org/issues/87 and @arvidn suggested this further improvement regarding sending the `info_hash_v2` parameter to reduce the number of requests. Since apparently it's not in the...

If it was implied then the reason for the discussion that took place in #87 wouldn't exist, no? Besides, stuff like that should always be explicit in documents such as...

> I'm not sure what you mean. Are you saying that it's _not_ implied? Yes, I'm saying that it is not implied. One of the sentences in my original post...

Yes, the first part is implied so the focus of the PR is to specify the second part. Your wording sounds better to me so I'll update the PR tomorrow...

> What is easiest for the client depends on how it's implemented, i.e. whether it's a) two separate torrents which happen to be backed by the same storage (plus minimal...

@the8472 I don't quite understand what you are trying to say. What "backwards-compatibility and adoption friction" problems is gonna cause if a v2 client announces only with the v2 info_hash?...

I still fail to see what you are trying to get at or in what case would that present a "backwards-compatibility and adoption friction" problem, but if that option is...

Ok, I guess that answered even the question that I added afterwards in my previous reply 😄

> I suggested announcing stats to the v2 hash, but obviously still announcing to v1, just no stats. @arvidn Why would you want to do that? From a tracker perspective...

> was there any resolution on this? libtorrent master implements bittorrent v2. However, it hasn't been released yet, so you would have to build `client_test` from source. I know libtorrent...