Arvid Norberg

Do I understand correctly that the scenario you're describing is when you *do* get a response from the DNS, you just get an IP that's invalid in some way, yeah?...

I see. So the DNS cache is fine. There is no need to invalidate it, the tracker just need to be retried (using the IP its name resolved to the...

Ok. I was trying to distinguish between re-resolving and re-connecting. A tracker that can't be connected to; I don't think it's safe to assume re-resolving would make a difference. Typically,...

> it is expected for the client to simply use another of the IPs. Do the recent DNS cache changes prevent this from working? No, and the DNS cache isn't...

> > Are you sure the problem is that the IP doesn't work and that you get a different IP when re-resolving? > yes, will be useful if DNS returns...

it's true that adding a field to hold the i2p destination in `peer_info` would break ABI. An alternative approach would be to ensure the peer-id is unique (or maybe even...

> Base32 I2P address is base32encode(sha256(base64decode(destination))) with removed trailing pad characters, converted to lower case and appended with .b32.i2p. So, exposing the SHA-256 hashes for peers, that would be a...

> Not sure what place are you talking about, but full base64 keys are needed for interactions with SAM. That's not what the documentation says ([here](https://geti2p.net/en/docs/api/samv3)): > NOTE: Since about...

I don't understand what point you're making. My reading of the document I linked to allows me to `SHA-256` that base64 encoded destination string and use that hash to refer...

@orignal it's even documented and officially supported by now (as I quoted [here](https://github.com/arvidn/libtorrent/issues/7346#issuecomment-1483925109)). @glassez how does this look? https://github.com/arvidn/libtorrent/pull/7356 There are a few other commits in there to fix up...