Vort

Addresses are now displayed correctly: 

I made one more test - downloaded torrent with large amount of peers in mixed mode. Some time after download finished, crash start to appear: ```text libtorrent::assert_fail assert.cpp:362 libtorrent::lcrypto::hasher256::update hasher.cpp:216...

Ok. I have 1 more crash, which happens while exiting qBittorrent. Most likely, unrelated to this change, but I'm showing it just in case: ```text ntdll!ZwWaitForMultipleObjects 0x00000000773692ca KERNELBASE!GetCurrentProcess 0x000007fefd151420 WaitForMultipleObjectsEx...

> I suppose you built qBittorrent with Qt 6.5, right? https://github.com/qbittorrent/qBittorrent/issues/18841 No, Qt 6.5 have no support for my OS (Windows 7). Because of it, I'm using Qt 5.15.8.

> I doubt qBittorrent could affect it. It should be reported to libtorrent instead. You are right: https://github.com/arvidn/libtorrent/issues/7387

Did you tested metadata download right after client is launched? There is some problem with SAM in i2pd, which makes connection attempts take longer if client if online for some...

I noticed similar problem. It looks like tracker for some reason need to be contacted twice: for metadata download and for file download. Not sure if we are talking about...

> Download doesn't start at all for me... Merge went wrong maybe? I tested this one https://github.com/Vort/qBittorrent/commit/de83ba192e02cb5eb91566c7bcb5b9d4f5ed7962 + changes to make 1 hop length. And I see the same problem...

> but if they exist and their computers have support for them, then I assume they will be able to use websockets and thus all Nostr capabilities through them, right?...

> Is this issue to implement, create a specific nip for this? I initially thought that such support require protocol changes. But after discussion, I understood that, most likely, anonymizing...