Unfortunately Freenode, after a takeover, decided to purge all their databases, thus
deleting all channel and user registrations, without a warning.
So if we're forced to re-register our stuff why not go where the cool kids are at?
Removed these two lines because they haven't been true in a very long time, and is no longer even possible.
```
You can also meet me (sledgehammer_999) on IRC:
`#qbittorrent on irc.freenode.net`
```
Stale bot will mark stale PR with a tag and close them after a specified
interval of time.
* Draft PRs are not subject to this marking.
* PR with an assignee or milestone is not subject to this marking.
Although the detection is working, the error message in autotools is not
perfect, i.e. it would only mention valid range for libtorrent v1 and it
shouldn't be a problem since v2 support isn't fully ready yet.
We can no longer save valid torrent files in the general case, because
for torrents of version 2, we need a full merkle tree to do it, but if
a torrent is added from magnet link, full merkle tree may not be available
even before the end of downloading all the data. Actually, we don't need
the full torrent file for the purposes of resuming the torrent, so we can
allow libtorrent to produce only a minimal part of the metadata as part
complete resume data, but we still want to store it in a separate file,
so we extract the resulting metadata from the complete resume data before
saving and merge it together before loading.
This allows the system to properly encode the '|', instead of passing
the '|' on in the URL, which is not allowed and breaks proxies such as
Authelia.
Then, for the purpose of generalization, I pushed this pattern through
to all places where we join items with a '|'.
This comes with the caveat that when we have individual components which
contain a '|' or any other character that is not allowed per the
HTTP standard, we still like to encode the individual components,
for example in the case of 3 strings, separated by a '|'.
If we don't do this we run into the risk that upon decoding URI finds
'|' in our original strings, which is something we don't want.
For example:
Sender:
````javascript
const arr = ["foo|1", "bar|2"];
const uri = new URI("test.html").setData(arr.join("|"));
````
Then on the receiving window, when it receives the uri and splits it, it
looks like this:
````javascript
const arr = new URI().getData('hashes').split('|');
// arr is now ["foo", "1", "bar", "2"]
````
This is why when we want to send a literal "|" we need to do
`encodeURIComponent` and `decodeURIComponent` manually on each item,
and THEN we join.
For example:
Sender:
````javascript
const arr = ["foo|1", "bar|2"];
const uri = new URI("test.html").setData(arr.map(encodeURIComponent).join("|"));
````
Receiver:
````javascript
const arr = new URI().getData('hashes').split('|').map(decodeURIComponent);
// arr is now ["foo|1", "bar|2"]
````
We don't need to with hashes as they are HEX, so no risk of any weird
characters in there.
Chocobo1