-
Notifications
You must be signed in to change notification settings - Fork 101
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Synthetic migration torrents #130
Comments
This isn't generally possible since v2 requires aligned files while v1 does not by default (the padding required to align files is an optional extension). Additionally calculating the hashes requires access to the files, it can't be calculated from a torrent, so it wouldn't help people who start downloading a torrent. Since only seeds can participate in such a torrent it wouldn't be particularly useful. |
it would be more useful than you think, especially for near-future applications. (maybe you don't want v1 torrents in your app, but you know ppl are gonna try to use them anyway, so you make a compromise and automatically convert to v2 whatever they download as v1. and if someone else tries to do it to the same torrent, they merge together since they're both created with the same algorithm.) this also means we don't need to care about (un)padding as long as it's consistent. |
You didn't really explain under which scenario it would provide an improvement. |
|
The benefit of that isn't clear. Those aren't hybrid or in any way backwards-compatible torrents, so you're just downloading content and creating a separate swarm (there won't be any sharing between v1 and v2 for most people, unlike hybrid torrents). The only thing that changes is that two people could create the v1->v2 separate swarm independently from an old torrent. But that only works if you have a v1 torrent for those two people to start with. I don't see the significant benefit over |
the benefit is to deprecate v1 torrents entirely, because every time you re-share a v1 torrent, it becomes v2. anyone sharing that, shares a v2 torrent. it creates a one-way pathway for existing v1 torrents to become v2 torrents in the near future, even if not all of them go through the process. it's about preservation. |
Yeah, no... it still doesn't make sense. On the one hand it relies on individual action (users taking a v1 torrent and turning it into a v2 torrent) and on the other hand it requires some powerful entity to steer people towards using v2 torrents. Even assuming that both of those things exist it's only a marginal improvement compared to one person taking a v1 torrent and reuploading the content as v2. Currently there's no plan deprecating v1 entirely, for now increasing v2 support is more important. It may happen some day, but at that point old torrents might have died naturally (no more seeders) or people already migrated them. |
no, it relies on automated action (client converts v1 torrents into v2 torrents, copying an added torrent always copies a v2 magnet) and enables multiple clients to do it the same way (so anyone who's fully downloaded a v1 torrent automatically seeds it on the v2 side, so nobody has to carry the v2 side alone), as clients get updated they automatically start seeding the synthetic v2 versions of these torrents and everyone wins. |
Similar suggestion here. I think to be useful, you would need a protocol enhancement that clients can optionally share or receive automatically generated hybrid torrents when they look for a v1 torrent. So once someone rechecks a V1 torrent someone else looking for that V1 torrent can also receive a V2 hybrid torrent. This would lead to better swarm merging and more resilient torrents over time. |
not particularly, just wait for users to share the torrent by clicking "copy link" on their torrent client, and turn that into V2/hybrid. alternatively, the DHT scanners will also pick them up. maybe convince DHT scanners to prioritize V2/hybrid versions. |
Hmm, you mean something like bitmagnet? Yeah that could work. Or BitSearch could do this too I think. The advantage of a protocol enhancement would be that if a widespread torrent client like qBittorrent would implement this, people wouldn't have change their behavior or do anything. But eventually everyone get the benefits of more resilient torrents. Ideally you would create the merkle tree already while downloading, but I'm not sure if that works with the alignment of the pieces. |
Bittorrent v2 doesn't contain provisions for synthesizing v2 torrents from existing v1 torrents. This actually makes upgrading incredibly inconvenient.
It would be nice if clients could seamlessly seed "synthetic" torrents, deterministically derived from v1 torrents and their data, such that the synthetic torrents can be re-uploaded to replace the v1 torrents without losing all seeders (and without having to give existing seeders the new version torrents).
The text was updated successfully, but these errors were encountered: