I've slacked on 3.33 release after seeing obvious problems with I2PSnark, should collect some thoughts now.

All results from win32 with i2pd node.

✓ Tixati no longer crashes when un-checking both networks from Networks menu.

✓ Tixati successfully connects to I2PSnark peers that lack encryption handshaking. Previously, only rare incoming connections from them succeeded. You could try to disable encryption in settings altogether, but it had to be done before any peer connections were made (probably because of short-term blocking of misbehaving peers on I2PSnark side).

‽ Local destination for Tixati has no descriptive name in the node console.

‽ Default tracker list has some problems:

— Postman (the tracker) only tracks its own registered torrents. Unless Postman (the owner) is okay with getting random hashes (that can potentially appear in the future?) sent there, and increasing the existing server load, it should not be used as open tracker by default. Magnets from the site include its tracker link, so users should be fine if trackers are not stripped. Requesting removal.

— i32bd... seems to be dead, haven't seen its destination being available even once in months. Requesting removal.

— Omitracker is almost always alive, but it never produces meaningful replies, just errors. It is probably crashed or neglected. Unfortunately, availability checking services don't initiate the actual tracker requests. Requesting removal.

— One of the user sites registered in March runs a new tracker:
http://opentracker.fattydove.i2p/a
Monthly availability seems decent, and, hopefully, it will remain so. Can be added.

It is true that working DHT turns trackers into fallback option. However, it is also true that I2PSnark clients wait for quite some time between DHT updates, at least with many torrents loaded. With tracker, peers find each other instantly, without tracker, well, they eventually might finally announce their presence to the world. I don't know if there is a reason for updates that are not as fast as on the public DHT.

Unfortunately, most I2PSnark users never add non-default public trackers, so dg2 alone gets all their traffic.

‽ Here is an example BiglyBT plugin update torrent:
magnet:?xt=urn:btih:78459b77591107ce7e1e20fc1e7b584552bb9d3d&dn=plugins_azneti2phelper-win32_2.8.2.1.2.zip&net=Public&net=I2P&net=Tor&tr=http%3A%2F%2Fopentracker.dg2.i2p%2Fa
(public, free, open source link)

Tixati says “server reply overflow” after the tracker update. Well, duh, it has 700 peers. BiglyBT and I2PSnark do get data from the tracker just fine. Not sure which one is right about the size limits.

‽ As you can see, BiglyBT adds its own network flags to magnet links. I find it very convenient, and can only hope that other clients turn it into a de facto standard. It is really easy to use bare magnets and bare hashes with I2PSnark because it can only use the I2P network. You can just drop it into the client, send to someone else, etc. With multi-network clients, everyone must check which options are enabled each time, because I2P torrents often should not be announced to the Internet, nor your personal Internet torrents should all be announced to I2P. Bare magnets like magnet:?xt=urn:btih:abcd...7890 become dangerous. However, when you see magnet:?xt=urn:btih:abcd...7890&net=I2P, both you remember where it should go, and the client can automatically enable just the proper network for metadata lookup. This should eliminate a lot of accidental leaks. BiglyBT also alerts the user with network selection prompt if it sees any .i2p or .onion trackers in the magnet, but it's more error-prone (because BiglyBT doesn't (yet) have the straightforward network switch in the magnet window on the first step like Tixati).

‽ It seems that Tixati (using I2CP) and I2PSnark standalone (also using I2CP) sharing the same I2P node can't reliably connect to each other (i. e. the connection (almost) always times out, for hours). Not sure if it's some encryption properties mismatch, or specifics of sharing the local node, or maybe some i2pd bug. BiglyBT (also using I2CP) can successfully talk to both local Tixati destination and local I2PSnark destination, get metadata, get data, and all the rest.

‽ It seems that Tixati can't connect to some of the trackers at all, even though they are online (and report peers) in other client, and can also be reached via main HTTP proxy. simp, fattydove, and skank don't work for me after hours of trying, and I don't think I've seen them working in Tixati previously. I vaguely remember discussions about different encryption defaults in i2pd and Java I2P, or sites using non-default settings for their tunnels, or something similar causing online check failure somewhere because of inability to connect.

‽ r4sas tracker currently returns error 400 (bad request?) to Tixati, but that can be a problem on their side. The owner is an active developer, so I'll ask about it.

Non-I2P-related:

‽ If channels2.dat is deleted or renamed, nickname defaults to old style guest<number> instead of random name.

‽ Ignored peer addresses are stored in channels2.dat, too. Ignoring a couple known bad peers is much faster than setting a proper IP filter by copying their addresses manually to a file.

great post!
Now this is stupid. Not the idea, but the intention & implementation.
First of all, why does it start with a capital letter P, I, T? This will get lost along the way and now everyone's subject to case-insensitive matches of &net.

Secondly, this acts as nothing more but a hint. An unsupported client will ignore this. If you were intending for this to be an opsec enhancement, this is not, because it'll be silently ignored. Solution? A separate scheme like magnetsec: that would require a supporting client to understand every field before continuing.

Obviously, the case doesn't matter. It is simply copied from BiglyBT which constructs it that way because it's cute. Remember the time when domain names had proper capitalisation in software and in print, even though it made no difference to DNS?

The catch is that I don't use “any” client. I use certain, specific program, and I know that adding network parameter flags changes the default network selection (which might or might not be what I want at the moment) to specified one. It is possible to change it afterwards as many times as you like.

Other clients should always ignore unrecognised parameters in magnet links, and they have been doing it since the beginning. A lot of additional ones have already been introduced. For example, both Tixati and BiglyBT add xl (total size) for a similar use case (text-based annotated metadata exchange, channels and user profiles for the former, DHT announces, searches, and messaging for the latter). If a client has no idea that I2P and Tor exist, what should it do with that information anyway? It's the user's business to understand which program should be used.

Magnet links are made for humans. If there is no human in the chain, you can simply send JSON, bencoded data, or any other serialisation protocol.

In this case, backward compatibility is quite straightforward: magnet without net options is neutral and agnostic, you should decide what to do with it depending on its source, and your own ideas about security, magnet with net options strongly suggests to only enable flagged ones. You can override it, but that assumes you've made decision to do so.

The link above is just an example. There is no real need to set all three networks at the moment. BiglyBT just has too much going on (6 I2P DHTs on 4 I2P destinations, Azureus/Vuze type DHT IPv4, same for IPv6, BiglyBT type DHT, Mainline type DHT IPv4, same for IPv6), so it checks peer sources and allowed plugins and trackers everywhere in the code, and the flags spill to the shared links. Also, if something else appears on the scene in the future, setting just those three will make sense.

These aren't prescriptions of one true way of doing everything, just the discussion of some pain points of interoperability. I2PSnark works with plain magnets and hashes because it never accesses the outside world. People share that inside the network. It is easy to add a trivial script to process magnet(s) in the clipboard, but it would be great for I2PSnark to also set the network on export.

Other convenient option is ability to copy generic magnet link and I2P-only magnet link for multi-network torrents (the main difference is just the addition of a network flag parameter). This stores the intent both for you, and for someone else who might see it. It also might lead to ability to add I2P trackers to I2P magnet links reliably, because right now you can't even choose which trackers get into the template string. As I see, I2P trackers are handled differently, have their own settings, so it's a bit misleading to lump them with internet trackers. BiglyBT's Sources tab — which dumps totally different stats there, and lets user make very different actions (or nothing at all) depending on the items they selected — is an example of how not to do it, in my opinion.

Some other problems.

‽ When I2P is disabled in settings, all torrents are promoted to public.

If any of them is started by accident, it starts getting peer connections over plain old IP. Old time software herders like us almost expect this exact thing to happen, but it's not the best choice, people might want to disable I2P for a moment to change node settings and be very surprised, etc.

‽ Tixati generates a bit too much of idle traffic.

I used a client with just about 40 public torrents for testing. Most of them were set to use both public and I2P network, some were I2P only, some were public only. Most of those did not have any I2P peers, so no torrent data was transferred. All torrents got a set of public I2P trackers.

Averaged over an hour, I2P node had shown about 20 KB/s of incoming and about 40 KB/s of outgoing non-transit traffic. Idle node without any clients uses about 2-3 KB/s both ways. For reference, 40 KB/s can be the total bandwidth limit set for certain small I2P nodes. That's also significantly more than public traffic Tixati uses when idle. Something's not quite right.

One obvious problem in I2P debug monitor is stalled connections to trackers (the ones to which Tixati can't connect for some reason, see above). Each torrent has its own timer for trackers, and the timeouts are much longer than with TCP/UDP, so they collectively slam the address with 15-20 connection attempts at the same time. Presumably, each attempt generates some wrapping packets on I2P network, so that's why we see the bigger number for outgoing traffic.

Peer connections are also made in the same manner in which they are cycled on the IP network. Test each known peer in the list, when finished, start again with unsuccessful ones, repeat a couple of times. Too many futile connection attempts. Things move much more slowly on I2P, and if some destination is not found, it is highly unlikely that it will reappear in seconds or minutes, there is no point brute-forcing it. Much stricter exponential backoff is required for both unreachable peers and unreachable trackers.

DHT is another suspect. Do its graphs show the total traffic, or public only? If those are totals, then about 2 KB/s or less is nothing to worry about. If I2P DHT traffic is unaccounted (I can't see any activity in I2P monitor), then some reasoning should be done about how much external bytes each single request generates, and how often they should be sent. It seems that a couple of active I2P torrents with some I2P peers and without any trackers result in 10 KB/s or less of additional traffic over half an hour. A lot better, if we keep in mind that most of those 40 torrents running previously did not have any peers, and shouldn't have generated significantly bigger traffic at all. It's also symmetric now.

I'll check how much I2PSnark affects traffic when idle later.

I screwed the measurements, but it seems that idle I2PSnark with a dozen of torrents active, very little peers, no leechers, and DHT serving other clients adds a single digit kilobytes per second to node traffic both ways, and when starting more torrents (about 150) with a lot of peers in various states, and seeding to them, incoming traffic (protocol messages, no local downloads) increases by 18 KB/s or less.

That's total node traffic observed in stats, with overhead, network lookups, tunnel housekeeping, and the rest.

If you go into settings and globally disable I2P, and then re-enable it, I2P torrents are not made public.  They don't lose their network selection.  And the I2P torrents are auto-stopped during the transition.

The only danger would be if you left I2P disabled, then decided to start some of the previously I2P torrents.

DHT traffic is indeed accounted for on the DHT charts, and it's actually very little.  You can observe if you completely disable clearnet, by going into Settings > Network > Connections and setting the interfaces to local loopback (so clearnet is disabled).  Then delete dht2.dat in the tixati config folder and restart the program.

The diagnostic I2P monitor is only for debugging connection-oriented sockets (eg. peers, trackers).  Doesn't track datagrams.  But you can watch them in the DHT event log if you turn the detail level up to 5.  You can also notice other interesting things in that log.  For example, the BiglyBT clients have an incorrect get_peers message that sends corrupt info-hashes that don't match the eventual announce messages, which have the correct info-hash but a mismatched token.

kind offtopic ~ by Guest on 2025/05/01 hh:25:59 PM
What doesn't matter is my nitpicking. However URIs are case-sensitive, it's not DNS. The magnet links are barely human-readable too. The &xl parameter for size you mentioned is a good example. What does it stand for? What's the long number? It's not interpretable on the spot.

The current &net approach is fine if you see it only as a hint. It is dangerous if you intend a strict network separation as some users may require. Unsupporting clients introduce the element human error, when &net is ignored. I've seen enough people gettinf in trouble and asking "how did my IP leak".
On the other hand, BiglyBT's I2P-only configuration is flawed, the wiki describes how it's reset with every update: https://github.com/BiglySoftware/BiglyBT/wiki/I2P#biglybt-updates

On topic
Further, I don't understand what this magic sauce is supposed to be?
https://github.com/BiglySoftware/BiglyBT/wiki/I2P#network-mixing

Generally I agree with you, but there are two strictly separate use cases not to forget about: intentional cross-seeding between networks (what I intend to do) & i2p-only torrents. Simply "flashing" the presence of a hypothetical i2p-only torrent over clearnet DHT could get you in trouble. If only the NationalSA and the likes actually cared about BT. Thankfully they don't seem to care or lack the qualification for such a project. Or both.
Workaround: I guess tracker+private flag for i2p to the rescue? It's only a workaround, because private flag calls for a strict swarm separation when switched from tracker A to B.


hanks for interesting data. I'm fascinated by your attention to detail :) I'd need to test I2P-mode well and keep an eye on it before I add my 2 cents. I can generally agree that timeouts, trackers, peer in/out connection attempts are problematic with Tixati. I2P is a different beast and can profit hugely from specific optimization. It looks like the dev is interested and having fun too. Catching those edge cases as he always does. Great to see this!

Have a good day everyone!