In that same time, the I2P Network has become faster and more reliable, and accessible workarounds to Git's non-resumability have been developed.

What's that?

The reason we stuck with mtn for so long is that mtn checkouts are always resumable. You can get partial ones and pick up right where you left off. It was an incredibly important feature, and one that Git still does not implement for git clone. To do a successful checkout on the old crypto required checking out at --depth 1 and even then could take multiple attempts. Things are much better now, but it's still comparatively slow and inconvenient to check out a ~389mb repository over git than it was with mtn. But git is resumable once you have at least a shallow clone, and moreover git can produce a git bundle which is a file that works exactly like a git repository for the purposes of cloning. So what you do to turn the crisis(git non-resumability) into an opportunity(redundant copies of the whole damn repository history everywhere) is start is you start generating git bundles of i2p.i2p every once in a while, at regular intervals(I recommend the tenth of the month) and distributing them with bittorrent-over-I2P. That way, you can download a near-complete copy of the repository from many peers and spend a minute or two --unshallowing the result, rather than cloning to --depth 1 and repeatedly --unshallow until you have a complete repository.

There are actually even cooler things you can do if you apply some git-transport magic and a way of providing a single memorable alias to a series of infohashes, there are some systems that do this it's just a matter of porting their dependencies into the I2P network or replacing them.

So this workaround is not client-side only, a little pity.

I guess since somebody has to generate and seed the bundle and for the time being, this is a scheduled rather than automatic task yes, this is not a purely client side solution yet. In a realistic future where we are able to do a similar thing, but with a git-transport that talks to the torrent client directly rather than by downloading a periodically generated bundle manually, the person seeding the periodic bundle could become much less important, assuming that most of the people seeding i2p.i2p through this hypothetical gittorrent-like system are updating to the latest code pretty frequently so that they're usually seeding pretty much the latest version. Swarm Merging would also be a huge help here I think. Then the only centalized(hypothetically) point you would have left is whatever you use to provide the human-readable alias you use to fetch the latest version of the corresponding(i2p.i2p) torrent. This is the part I don't quite get yet, I guess what other people(the gittorrent folks) have done is use a blockchain to distribute a list of infohashes associated with a given name that's registered by performing some kind of transaction? Not sure. Haven't had time to read up on that yet and every time somebody says "applied blockchain" people groan and say "are you sure?" I'm no different.