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.