When did I say that? It is the official I2P code host. I'm a member of the I2P team, I run the service, we own the "I2P Developers" namespace. We approved the TOS before they went into effect on zzz.i2p. We require GPG for our commits so all the checkins are attributable to the person who checked them in. People who want to can file an issue with the TOS in the TOS repository I linked before. I can't guarantee that I will take action on it but the catch-all answer behind the answer to issues with my TOS is to host more competing git hosts on I2P, which I wrote an easy-to-follow guide for that is linked prominently in the TOS.

It's open to the community so the community can contribute, and host their own code if they want. In the same way another team member ran the old mtn host. The only difference is that I can allow people to join gitlab and use it as a public code host, whereas mtn was open only to the I2P team.

I am familiar with this complaint, but it came a little too late for me to change the hosting service decision from Gitlab to Gitea. That being said, since I generally consider gitea a little more managable for smaller, self-hosted deployments, and since it's pure-Go and a little more monolithic, it will be slightly easier to set it up to be self configuring with SAMv3. So give it a little time, and I'll make Gitea I2P-Native.

TL:DR because I write the TOS. It's a service hosted and administered by me, personally, and made available to the community. I'm not a corporation, I don't have staff, I kind of have a datacenter but it's actually just a bunch of old desktops and a switch, and I have non-gitlab responsibilities. I have to make policies that keep this service manageable for me to administer and that means things like not allowing people to potentially automate registration. The fact that I have to go in and approve accounts case-by-case means that automatic registration is almost moot point and I don't have to set up a captcha.

If my TOS are not satisfactory, I also wrote a guide to hosting your own gitlab service on I2P using gitlab: http://i2p-projekt.i2p/en/blog/post/2020/03/16/gitlab-over-i2p which is still accurate. It can be hosted on old hardware, raspberry pi's, probably with enough hacking a chroot on a phone if you wanted. There are plenty of other easy-to-setup git services like gitea, cgit, gitbucket, or whatever else anyone wants. Just point a tunnel at the web service and the SSH port and set the http_proxy environment variable to the value of an HTTP Proxy.

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.

The time for I2P comes when people bring it, I think. If we think of I2P as like the internet, then what brings about it's time is applications that popularize it. I'm not sure what that application or group of applications will be, but a better way to configure and launch browsers on multiple platforms might be part of it, and obviating the installation of the JVM/OpenJDK for Windows users is a part of it too.

Mixing social elements and peer-to-peer file sharing might be another, like a f2f microblog/messenger/torrent tracker for sharing files privately. Sharing a single b32 for every peer would have to go though, I would use Magic Wormhole to generate a short phrase which contains a link to the real b32 gateway to their node. Or somebody who has more time/likes node better than me could port WebTorrent, that would bring us all the really awesome stuff that people build on top of WebTorrent all of which is incredibly cool and useful. I really want to see more games, even simple ones. Chess, checkers, backgammon, either using traditional chess servers or something modified to be peer-to-peer. Freeciv long-turn games. Up to a point, even real-time games are possible with short, multipath tunnels. Games are neat because they occupy a social context which is not widely considered a part of the anonymous internet, even though major services have emerged and been successful in marketplaces largely because of things that happen because gaming is not tenably anonymous.

What I think these all share is a tendency to be "Fun," the ability to be "Easy," and for that to produce a "Network Effect." People don't join networks to talk to no one. Sometimes they join networks to talk to themselves, but mostly they want to do things with other people. Finding new ways to facilitate people doing new things with other people is what I think grows I2P.

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.

It's working for me in I2P in Private Browsing WebExtension. I'm going to have to make some improvements to the UI/style for this on my end though, it's doesn't show up very well when the URL's are this long and that's a problem that needs to be solved. Next release is likely to happen Sunday, and I'll be sure to include some improvements to the feature in that release. Thanks for setting this up.

I really like Go for its simplicity, ecosystem, and ability to develop applications and libraries in rapid, understandable ways. In particular it is easy to integrate Go applications and libraries with anonymous networks thanks to libraries like goSam, sam3, and bine. Obviously in the browser JavaScript is the only way to fly. Brief love affairs with various JS transpires taught me I should just get better at JavaScript.

Admin here. Reply in the thread if you need an account approved :)

Lots of ways now :) but this post was made with I2P for Android, IceRaven, and the I2P Proxy WebExtension available in IceRaven's default collection by accessing https://ramble.pw which is working very well.

http://i2p-projekt.i2p/en/blog/post/2020/12/10/Hello-git-goodbye-mtn

Funny you should ask, i2p.i2p migrated to git literally 17 minutes ago! I2P source code is here now: http://git.idk.i2p/i2p-hackers/i2p.i2p

re: alreadyburnt I actually didn't intend to keep the account. It was intended to signal "Do not reply to these messages, because this account is already burnt." That said, somebody could probably find me if they really tried, but I'm not like a radical of any stripe or a market seller or anything like that, most of what I do is pretty uncontroversial, I just genuinely believe that P2P and Privacy describe characteristics that ought to be normative of the bulk of normal people's online activity, and that now is the apt time to participate in how those concepts affect humanity's future.

Re: my anonymity, some of my colleagues know my first name, and the really-high profile adversaries surely know who I am, I have been on camera talking about I2P plenty of times, I've had to book plane tickets, I pay my taxes. I lock down tight and try not to piss people off too much.