Do-the-work instead of proof-of-work, for Git hosting - The Lego Mirror
Do-the-work instead of proof-of-work, for Git hosting
By Kunal Mehta
Sun 14 June 2026
in Tech<br>tagged freedom, git, offline, rust
The insane rise in scrapers across the web has affected a number of websites, including Git repository hosters. The main response has been to set up software like Anubis, which uses a proof-of-work system to limit who can access the website.
While I don't fault overburdened sysadmins for enabling Anubis to protect their servers from overload, I think it's a pretty bad solution. It introduces a delay, wastes energy, and just makes the user experience worse.
We've spent so, so, so much effort and energy squeezing out milliseconds of performance and optimizing connection times that deliberately making performance worse feels like a giant step backwards.
And the work the client does is just thrown away! It's not actually anything useful; people rightfully critized Bitcoin and (formerly) Ethereum for being wasteful for the same reasons.
So I'd like to propose a different solution, which I call "do-the-work".
In a traditional setup, it is cheap for a client to send a request to a server, the server performs some potentially expensive computations/processing and sends back a response. With scraperbots, it becomes easy for those clients to very cheaply send thousands and millions of requests that overload a server.
With proof-of-work protection (i.e. Anubis), the client it must perform its own computations, and only once it's done sufficient work, then it gets permission to send a request to the server. The server does more or less the same amount of work, it's just that the client now also has to do some work.
Do-the-work aims to invert the client-server imbalance by making the server's job cheap and forcing the client to do the more expensive computations. In other words, if you want to see some information, you need to pay the costs of calculating it by... doing the work.
Because of the way Git is designed, I think it's a great fit for this approach.
A client-side Git viewer#
As previously teased, on git.legoktm.com I am now serving an entirely client-side Git repository viewer (source code, README), which imitates the look of cgit (used by e.g. git.kernel.org). On the server-side, it is purely static hosting of bare repositories, requiring just Apache HTTPd and a few rewrite rules.
The only thing I really need to worry about is bandwidth, but since it's now static content, it would theoretically be straightforward to put it behind a CDN.
Since most of my personal projects are quite small, I've mirrored a few larger projects so you can better see how it works: SecureDrop and MediaWiki. All of these repositories are maintained in my private Forgejo instance and I rsync them over to git.legoktm.com.
Under the hood, Git stores everything in "objects", so as long as you have some way to fetch those, then you have all the information you need to calculate everything a Git viewer needs, like file contents, diffs, a log of changes, etc. In reality it's a bit more complicated with pack files, but at the end of the day everything is an object.
Most git clients expect this to be filesystem backed, but cyberia-ng's git-async library abstracts the backend out. So I created a new backend that fetches over HTTP and stores the data in IndexedDB in your browser.
Essentially you're performing a partial git clone and then automatically backfilling missing objects as needed.
There's probably a lot more room for performance improvements, but I think it's already usable enough for small-to-medium-sized repositories. This doesn't cover everything a forge does, but if you're just hosting cgit, this should be a drop-in replacement (aside from all the missing functionality).
I think this approach can be better for privacy too. After the initial load, a subsequent load when nothing has changed on the server doesn't require fetching any more data; it wouldn't take that much more work to behave fully offline.
For now this is mostly a proof-of-concept, but I think it's probably not too far off from turning into a real thing that's usable if there's interest in that.
Social
Git
Mastodon
last.fm
Planets
Wikimedia (English)
Debian