Log In     Register    

Help and Support
Ask a question, report a problem, request a feature...
<<  Back To Forum

Submit BEP proposals for BitTorrent v3 and v3.1 protocols
Page 2 of 2     <<<12   >   >>  
by Guest on 2026/03/21 10:20:43 AM    
I think other torrent developers will be more kind towards Tixati's new protocols if he renames them to

v3 = v1.5 and

v3.1 = v1.8

I mean this is the best way to put it considering the documentations presented by Tixati itself.
by Guest on 2026/03/24 05:34:49 AM    
I followed up on your earlier point about how the newer protocol versions are classified and asked a Tribler developer, and their view seems to line up with what you said.

From what I understand, Tixati protocols v3 and v3.1 are more like extensions or iterative updates to protocol v1, rather than completely new protocol frameworks like BEP52 ( https://bittorrent.org/beps/bep_0052.html  ).

So from that perspective, it might be more accurate, at least in terms of naming and documentation, to treat them as incremental updates, like part of a v1.x series, instead of calling them entirely new versions.
by Guest on 2026/03/26 08:28:13 AM    
I2P developer confirms they will not move forward with this implementation until and unless a BEP is submitted via official https://bittorrent.org/beps/bep_0000.html  or https://github.com/bittorrent/bittorrent.org/pulls

Well, the ball in now in Tixati developer's court, if he wants this feature adopted widely or not.
by Guest on 2026/03/31 07:37:34 PM    
One thing I don't like about "v3" is how it is presented in the Tixati client.
Calling v2 "old" and hiding it is a bit disingenuous, especially since "v3" is just v1 with extra steps.

Backwards compatibility is one thing, but it changes the infohash anyway.
by Guest on 2026/04/03 07:01:57 AM    
My man, as a layman, I did whatever I could do to convince all torrent developers to implement v3. Now, it is your turn to explain to developers. I think they need some developer talks to understand the things that a layman cannot tell them or layman does not understand itself.
You need to now, take up the mantle and come out to solve developer's confusion or doubts or whatever they have. https://github.com/arvidn/libtorrent/issues/8047#issuecomment-4105702173
by Guest on 2026/04/22 07:28:52 AM    
BEP v3.1 still not avaialble and neither is BEP v3, on BitTorrent GitHub.
by Guest on 2026/04/23 07:40:17 PM    
My opinion as a normal user (quick thoughts, hopefully I'm not wrong about anything): I think both the v3 and v3.1 protocols are brilliant, but should be done and named differently. I think the security improvement in v3 and v3.1 is critical, so the approach of implementing it in a backwards-compatible way is correct compared to the approach of waiting for v2 to be adopted more broadly. I like that there's a way to specify the cryptographic hash algorithms, instead of having a hardcoded algorithm. I think v2's property of allowing recognizing identical files across different torrents is a groundbreaker for potentially better longevity for torrents and saving disk space for users.

I think v3 should be called an extension of v1, or call it v1.5 (because of the major improvement it brings, rather than v1.1 for example which doesn't do justice with the improvement). When creating a new seed, it could show as a sub-checkbox under v1 saying something like "Augment with secure metadata (fully backwards compatible). Exclusive to Tixati." The latter comment could be dropped when it would become an official standard.

Since v3.1 is incompatible with v1 and v2, and seems to me on a quick read to be incompatible with v3 too, I don't understand why it was built on top of v3/v1, instead of v2. Furthermore, since it's incompatible with the other protocols, and I suggest renaming the current v3 protocol away to another name/number, I think it makes sense to add all the innovations from the current v3.1 on top of v2, and call the result v3.

Ignoring hybrid torrents, this would result in having:
1. Insecure v1 (current v1, hidden by default for security)
2. v1 with security (current v3)
3. v2 (current v2)
4. v3 (a result of taking current v2 and adding current v3.1 innovations (including those also of current v3, e.g. cryptographic agility) on top).

Since neither v3 nor v3.1 are standardized yet, it isn't too late to rename them.

In any case, thank you
Page 2 of 2     <<<12   >   >>  
<<  Back To Forum




This web site is powered by Super Simple Server