[the8472]

The DHT BEPs specify a network that is only barely related to the bittorrent core protocol, they can already be used independently, and some people do.

> I feel like trackers were largely overlooked in this update, but I'm biased because I work on a popular tracker.

Yes, we did not pay much attention to trackers, but BEP52 basically seized the opportunity to do some incompatible changes we always wanted to do anyway (quite a few accumulated over the years), and there were no such open issues with the http tracker protocol.

[jzelinskie]

>...and there were no such open issues with the http tracker protocol

This is because the HTTP protocol is so much overhead that most trackers don't even really run it anymore. I think UDP being promoted to the spec would've been a step in the right direction. Modern trackers have a bunch of tricks like BEP34[0] to avoid getting pounded that would be great if every client conformed to.

I hope I'm not coming off as aggressive. I really appreciate this work and I'm really glad to see a spec revision. It's just as you said, there's been many years and many good improvements that I'd like to see made while there's still a change to break things.

[0]: http://www.bittorrent.org/beps/bep_0034.html

[the8472]

I still don't see why this would need to piggyback on a breaking change of the metadata file format. "Please use UDP by default" is fairly orthogonal to the metadata format and could be added to the spec at any point if we want to.

HTTP trackers are considered fine for medium-scale torrent deployments. UDP trackers were originally introduced to cope with the traffic caused by running an open tracker that manages 100k+ infohashes for the whole world.

Also, both BEP3 and 52 already forward-reference the tracker extensions (compact and UDP), so someone who writes a new bittorrent implementation should already be aware of them.

Maybe we could make it more clear that some BEPs are almost-mandatory.

[aninhumer]

>The DHT BEPs specify a network that is only barely related to the bittorrent core protocol

Yeah, if I remember correctly bittorrent DHT ultimately just maps 20 byte hashes to peer-lists (IP + port pairs). It's obviously designed to be convenient for bittorrent swarm discovery, but nothing about it limits it to bittorrent usage. Indeed, I'm surprised it's not more widely exploited for p2p bootstrapping.

[pdimitar]

More generic question, apologies if it feels inserted without relevance:

Did you guys talk with the IPFS team? Do both of you have a desire to start bringing both families of protocols and technologies closer together?

I feel in this age we must make de-fragmentation of efforts our topmost priority.

[predakanga]

How do you intend to handle incompatibilities in the tracker protocol that are introduced by BEP52?

In particular, I note that there's nothing in there regarding which infohash should be used in the tracker updates. Should traffic with v1/v2 clients be reported separately, or should it be consolidated under the v2 infohash?

[the8472]

hybrid torrents essentially consist of two swarms, so you announce twice.