Editing/adding multiple HTTP(S) sources; adding other protocols (RSYNC, FTP, GIT) to "web sources"

Please provide the following information

qBittorrent version and Operating System

qBittorrent 4.2.1 (x64) on Windows 10 Pro (x64)

What is the problem

For now adding alternate HTTP(S) sources for any torrent is very unfriendly, there's no easy way to do that with the UI

you have to guess that you can right click the blank area of the panel to see the contextual menu to add/edit/remove an entry.
the input box in the popup that comes in for adding/editing a source is too narrow for most links we want to add
we can only add/edit a single HTTP source

What is the expected behavior

Like when editing trackers, we should be able to select a torrent and open the menu (which already contains the useful option "Edit trackers..." to edit them all at once) that should include the option "Edit HTTP sources..." as well.

Then we could edit the full list, one URL per line. And we could easily import a list of URLs (e.g. by copy-pasting from the HTML source of a web page, from which we'll easily find occurences of href="http..." in order to import this edited list without error or ommissions

(this would allow including long list of web mirrors, that the torrent would also complement to help them sustain more workloads; these mirrors could be on servers also offering torrents, but there's generally no link between them, because the torrents do not track and redistribute the web sources, that are essential to maintain torrents in a safe connected state and without forcing users to choose from a few single websources that are overloaded when many are underused and will still be useful to terminates downloads and resharing of torrents; torrents would as well be helpful to help web mirrors keeping synchronized contents in their archives).

This would benefit a lot to linux distributions for their installable ISO or updates (including LTS, stable and testing versions) to help their development by allowing them to reduce their own web hosting costs and sustain good performance on their own hosting servers.

And may be qBittorrent could support as well the rsync protocol used also by various mirrors to extend the rsync network and the torrent/DHT networks that complement each other. rsync would work like existing RSS feeds for maintaining a collection of related files in a collection reshared with torrent.

So the "web sources" (new name for "HTTP sources") in qBittorent could contain other protocols for URLs than just HTTP and HTTPS, it could also support FTP/FTPS URLs, RSYNC URLs, possibly even GIT URLs for specific file versions (which are also popular distribution for open source projects), with additional protocol plugins.

I'd recommend splitting this issue into 2:

Improve editing/adding HTTP/FTP sources UX
Enable other protocols for webseeding (including HTTPS)

The latter is not an issue/feature request for qBittorrent - it is more of an extension proposal for the BitTorrent protocol itself. The current webseeds protocol standard is documented here: http://www.bittorrent.org/beps/bep_0019.html

So please edit this issue accordingly to only focus on the first point.

@FranciscoPombal I tend to disagree. supporting other protocols in qBitTorrent (possibly with a plugin) is independant of the torrent protocol itself (except that there may be also extension for peer exchange protocols to support sending URLs for other protocols than just HTTP(S) and FTP(S); and another separate extension for "magnet:" URIs containing these URLs). Nothing prevents qBittorrent to offer an interface (via plugins) to other protocol handlers or programs (notably rsync and git): no change is needed for that in libTorrent, but change is needed in the qBittorrent UI to support such extensions.

As well my main query (for which you changed the title inaccurately) is lost now:

I asked FIRST to add a way (in the qBittiorrent UI) to add and edit multiple websources (for now HTTP and HTTPS) instead of just one by one, exactly the same way we can edit list of trackers.

Please restore my title. The rest was a discussion and clearly separate that adding other sources will need later other protocols than just HTTP(S) refered in the main RFE topic.

So please restore the title, at last that essential part: "Editing/adding multiple HTTP(S) sources" which is exactly what is described in the "What is the problem" section. And the next section before the clearly separating horizontal line (which clearly indicates a suggestion and talk about the direction for further separate enhancements) and why I suggest to name the UI option "add/edit web sources" rather than "add/edit HTTP sources": in all cases we'll be able to add/edit URLs to a list, one URL per line, like when editing tracker lists.

qBittorrent is not a general-purpose download manager, it is a BitTorrent client. Thus, it will never support downloading files with other protocols such as HTTP, FTP, rsync, etc either natively or through any sort of plugin architecture.

The extent to which qBittorrent uses/supports HTTP/FTP (via libtorrent) is limited to the strictly necessary for compliance with http://www.bittorrent.org/beps/bep_0019.html. This does not mean qBIttorrent supports HTTP/FTP downloads in general. It means qBIttorrent can request data from HTTP/FTP sources as if they were a seed.

So the part of the issue about implementing other protocols and the ways the GUI change could be related to that is invalid.

The valid issue here is the UX for adding new webseed sources. As stated in the contributing guidelines:

Post only one specific issue per submission.

You are always allowed to link between different submissions if they are related.

You say "it means that qBittorrent can request data from HTTP/FTP sources as if they were a seed". This means clearly that qBittorrent is a general purpose downloader. But the intent is to allow sources to combine: HTTP/FTP sources for some primary sources, that would request torrent seeds to help them distribute their files (torrents could as well be used to synchronize their HTTP/FTP mirrors, as well as rsync which is also used: mirrors tend to do frequent updates to their initial sources, but they do not help much each other, while they could all use as well torrents; so an initial web source would jsut have to also host a minimal torrent tracker, without having to track all web mirrors; the mirrors, compared to torrents , have a long term connectivity, but limited bandwidth capacity and they host a lot of files; torrents can help everyone reduce and share their costs, notably when today there are so many torrrent seeders that can offer decent bandwidth via the fiber accesses, even if each one can support a limtied number of clients and would limit each one to a 1 megabit/s without any problem on most fiber accesses and with hundreds of torrent seeders, these consitute viable sources at no additional cost and no lack of performance on most PCs running as seeders for long time and sharing only a small amount, but most of them would not become HTTP/FTP web sources without performance problems on PCs for other local uses). Nothing forbifs a toorent client to support hybrid protocols without even modifying these protocols. But there a good reason why hybrid distribution is a viable and enviable solution that will be very useful for free software distribution and as well for free database replication (where files are even bigger and not safe at all to download with HTTP or FTP alone: torrents can secure HTTP and FTP by the fact it also offers strong hashes at block level and not just at whole file level, and the fact they can also repair damaged files; web sources on the opposite offer stability for long term. Different protocols are not opposed, they complement each other to make the best use of what is connected on the internet, combiinng them offers scalability, reliability stability, and lower costs for everyone.

So you are saying that you do not want to change qBittorrent... Users will find their way by using other torrent clients that already have support of plugins to handle more protocols and combine them! qBitorrrent will then lay behind others (and protocols like rsync and Git are very common, and even used by you for developing this project! this is not an "exotic" requests with no use). it is possible to make a client that will combine all types of sources as a single unified resource, the client will automatically use what is the most responsive depending on the kind of remote peers or servers and their current state and activity.

You say "it means that qBittorrent can request data from HTTP/FTP sources as if they were a seed". This means clearly that qBittorrent is a general purpose downloader.

No, it doesn't. Go read the BEP I've linked multiple times above. I guess technically, if you just add a webseed to a torrent (no other trackers or DHT), the end-result should be indistinguishable from just using an HTTP downloader. But that is an abuse of the spec. Plus, in practice, web seed usage is very infrequent in the wild.

Different protocols are not opposed, they complement each other to make the best use of what is connected on the internet, combiinng them offers scalability, reliability stability, and lower costs for everyone.

So you are saying that you do not want to change qBittorrent... Users will find their way by using other torrent clients that already have support of plugins to handle more protocols and combine them! qBitorrrent will then lay behind others (and protocols like rsync and Git are very common, and even used by you for developing this project! this is not an "exotic" requests with no use). it is possible to make a client that will combine all types of sources as a single unified resource, the client will automatically use what is the most responsive depending on the kind of remote peers or servers and their current state and activity.

Use different programs for other protocols, or use a general purpose downloader that aims to support as many protocols as possible. qBittorrent is just a BItTorrent client, for people who just need a BitTorrent client. It is not trying to "compete" with other general-purpose downloaders. Would you think of opening an issue on curl or wget's issue tracker asking for BitTorrent support? There are different programs available for different needs, they don't all have to support everything. Perhaps aria2c is more suitable for your use case.

You keep driving this off-topic even more. Now you mention git? Please respect the one issue per specific problem.

I already cited Git in the first message. And the "different purpose" is fuzzy; actually there's a need to support torrents as a way to augment mirrors at lower cost for large software distribution (and this is already what Microsoft does now: not just a single HTTP downloader, but augmented by its own proprietary P2P protocol; as well with various Linux update tools). THe problem is for general software downloads: mirrors cost a lot to their maintainers, and they don't have enough mirrors, and if they have, the mirrors are not all used the best way as they could because people choose them without any performance indicator and are not as fast as they could. As well for very large files (gigabytes), classic web downloads with FTP(S) or HTTP(S) is not so reliable for many people due to unchecked transmissions errors, and even if these sites provide a digital signature, it is for the whole file: in case of error, and if the user actually performs the check, the whole file has to be downloaded again, and this costs lot of bandwidth to the servers, and lot of time for many users; that's where a P2P distribution by torrents can help, as they scale better, are more reliable and much more secure (against tampering), and recovery from some tampered data is much faster as you don't have to download again everything: even for web distribution, having a .torrent can help recover the damaged parts easily as the .torrent file contains many hashes that can check small fragments and isolate the errors (so a just few small HTTP(S) errors from the source web server will be needed, even if torrent protocol is not used for downloading these fragments). I see torrents as a cute way to extend the capaibilities, reliability, security, and performances for web distribution, and not just for illegal P2P file sharing as it is too often used (still causing many ISPs in the world to block the protocol or seriously slow it down by monitoring). Making both worlds (client-server and P2P) working cooperatively would extend the worldwide support of torrents, and possibly even allow integration in web browsers: there's not just HTTP(S) or HTTPv2; it could as well be used for legal streaming (still not enough used with torrents) and would be the natural way given the huge development of fiber access at home (and soon 5G mobile): using web hosting with large capacities would no longer be a (costly) requirement for many sites. and this would also profit for the use of P2P in private clouds, notably for transfers of large files (like system and database backups and not just small collections of files) without being forced to use a central webhosting with very large capacities, when there are now much capacities available but not used in P2P hosts with fast internet accesses (that are sometimes even faster than central servers on costly hosting providers and CDN). It is strategic: the cost of everything would be decentralized and users already pay a fast internet access they don't really use. I propose this integration to merge the two world: there's no real need for a segregation between client-server, server-to-server mirroring, and P2P.

And legality of shared contents is an unrelated problem which is independant of protocols used: ISPs should be protocol neutral in their service and this proposal is to extend the legal use tp make it a viable long term solution. ISPs and agencies can still easily locate illegally shared contents with the DHT and with partial downloads from torrents for identifiable signatures, theyr don(t need to block or slow down the P2P protocols - torrents, DHT, PEX - as they do today, which is now a strong limitation for the development of torrent networks and use of qBittorrent with more people using it safely and reliably.

Even for security against tampering, torrents are much better than HTTP(S) including HTTP v2 as all contents are checked in torrents, jsut like what Microsoft does with its own P2P protocol for Windows!)

Honestly I don't see how the webseeds protocol extension doesn't provide the interoperability you are looking for. And that interoperability is not really necessary in practice - just use plain torrents. The reason why many organizations don't just use plain torrents is precisely because of the association with copyright infringement. But that's their problem - smart organizations that can recognize a protocol's merits regardless of its illegal usage have been using it for a long a time. For instance, most Linux distributions use BitTorrent to distribute their ISOs. For many, BitTorrent is even the default distribution method.

Closing as invalid an not an issue because:

this is 2 issues in 1. I opened an issue focusing on the relevant one.
one of the mentioned issues (support downloading files with other protocols, in addition to what already possible via the web seeds protocol extension) is not a problem with qBittorrent.

qbittorrent / qBittorrent