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

I use NoScript, thank you. I can browse github without js most of the time.

What's this gotta do with Javascript?

It a) uses more resources, b) help fingerprinting, c) may disqualify your browser/os easier and faster because of bleeding-edge browser APIs that you mostly don't need.

Why do you need to approve an account? 🤔

Valid concerns, but maybe you misread. This is about GitLab, not Github.

I'm talking about all git services that uses javascript. GitHub, Gogs and Gitea cooperate better with NoScript. Bitbucket and GitLab are meh.

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 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.

I see... so it's not the official i2p code host? Maybe I need to reread that "monotone to git thing" 🤔

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.

It's a service hosted and administered by me, personally, and made available to the community.

I guess I misunderstood that.