How does Tixati handle Peer ID with I2P?

Say there is a torrent that is Network=All.  Will Peer ID be the same on I2P as on the visible Internet?  If so, this would allow an observer to map an I2P endpoint/key to an IP address.  (This is fine so far because Network=All is not anonymous.)

Now say there is also a torrent that is Network=I2P.  It will presumably have a different Peer ID than the Network=All torrent, but it will have the same I2P endpoint/key, which can be mapped to an IP address if the swarm of the Network=All torrent has also been observed (within the same I2P endpoint/key rotation).  So observing the swarms of both torrents would lead to de-anonymization of the one that is Network=I2P.

There's no indication in the UI that the Peer ID is different between networks, which is why I'm asking.  Or maybe I'm mistaken about something here?

And thinking about it a bit more, Peer ID would be only the most obvious signal to use for mapping I2P endpoints/keys to IP addresses for Network=All torrents; there would be others.  Maybe there should be a separate I2P endpoint/key for Network=All and for Network=I2P?

Keep in mind that the Peer ID is different for each torrent, so having two separate IDs (one for inet, one for i2p) within each All Networks torrent wouldn't accomplish too much.  As you said, there's other ways to figure out which public IP matches which I2P address within the same All Networks torrent.  But the I2P-only torrents would have their own unique peer ID anyways, since every torrent already has a unique peer ID now.

It still might be worth it though, just for making things slightly more difficult to figure out.

I think the real issue is, as you pointed out, having only a single I2P endpoint.  A separate one for I2P-only torrents would probably be worthwhile for a little added anonymity.  It wouldn't add much work to the I2P router.

OK, that's an old story.

The ability to handle public and private torrents in a single client is just for convenience. (Private in the widest sense, meaning anonymous networks, closed trackers, personal torrents for friends, and so on.) Independent destination (as in BiglyBT, which you obviously meant) only protects you from casual observers trivially comparing lists of peers on a unique set of torrents on both public and anonymous sides. There are still ways to match users by their activity profile, crosstalk on traffic profiles through connection with a fixed bandwidth, etc.

So treat such usage as a nickname on a forum. You don't announce your full name, but your friends know, mods can look up your e-mail, and it might leak after an unrelated hack. That's for torrents you can also share publicly, and there's not much need in long tunnels for those, so you can also set them to single hop. In simple terms, just to re-seed all you've got into I2P in case someone might want it. You can see it as if all those torrents were public by definition, and you've just chosen to stop seeding some of them via public interface.

If you want to remain anonymous (at least to a certain degree), you need to use an independent torrent client that has no access to the public side to handle anonymous torrents. Even background DHT activity can potentially be tracked by dedicated observers (if they can watch your traffic, it's even trivial).

If you really need to remain anonymous, and someone is actually trying to find you, that would not be enough. You'd want a client that is not in the same physical location with the node it uses, and fault-tolerant tunnel over multiple uplinks between them, and the backup power supply, and the secure environment to handle possible software exploits, and... seeding torrents is probably not the thing you should do in that case.

I didn't realize BiglyBT had this.
https://github.com/BiglySoftware/BiglyBT/wiki/I2P#network-mixing

Tixati should do the same.

Tixati v3.38 has a separate default peer ID for I2P within the same torrent.  And each torrent has it's own ID(s) as usual.

Very soon, possibly next release, I will expand the client profiles feature (Settings > Xfers > Trackers > Client Profiles) to have the ability to specify completely separate I2P peer ID, client ID, and so on.  The transfer's options tab will also have completely separate controls for the peer/client IDs for internet and I2P, so you can also directly customize these per-transfer if you want.

I will also be adding a separate I2P endpoint for the I2P-only transfers.

Thank you, OP, for your input.  I will do this very soon.