After 3 1/2 years, review is scheduled:

Tuesday June 24, 7 PM UTC, IRC2P #ls2

It would have to be implemented in each client.

I just posted a status update on remote search in i2psnark at http://zzz.i2p/topics/3687

GandalfTheGrey wrote: ↑12 Jun 2025 17:31 it's a lot of data to lose if there's a connection problem or disconnect.

Snark will not lose partial pieces on connection problem or disconnect. It only forgets them when the torrent is stopped.

provil wrote: ↑10 Jun 2025 10:45 Please do thank you.

So which is it? You want smaller pieces (OP) or larger ones ("please do")?

Strange. Don't have any ideas. Will try to reproduce here.

The linked issue is about SAM, your issue is with i2ptunnel (hidden services manager), but same concept. For some reason your HTTP client proxy is ElGamal-2048 only, and hq.postman.i2p is ECIES-X25519-only. Go to hidden services manager, stop your HTTP proxy client tunnel, edit it, change the Encryp...

Thanks for the post. I think you've overstated the benefits of small pieces and understated the costs. Also, clearnet torrents seem to be converging on the opposite philosophy. 20 years ago, snark did not handle large pieces and partial pieces well at all. Large pieces were not reliable. Today, all ...

Interesting test. Did you verify that all three clients have the same bandwidth limit settings?

Snark will query the router for the client bandwidth limit and hold to that. I don't know if Bigly does, and qbittorrent can't via SAM. So snark might be at a disadvantage here.

Best to leave everything the defaults. I2P knows you are IPv4 firewalled, and you can still use it for outbound, and with SSU2 relay you can still get peer-assisted inbound connections.

We plan to release 2.8.2 on Saturday March 29 to fix SHA256 errors reported by several users.

Translation and checkin deadline is Friday March 28 Noon UTC.