The End of Proof-of-Work: How Client-Side Git Hosting Changes Everything

• Introduction to the problem (scrapers overwhelming Git hosts)
• Why proof-of-work is problematic
• The "do-the-work" concept
• How it works with Git
• The implementation (client-side Git viewer)
• Benefits (privacy, performance, CDN-friendly)
• Implications for the future

Let's be honest — the internet is drowning in bots. Scrapers, crawlers, and automated scripts hammer websites with requests day and night, and Git repository hosters haven't been immune to this plague. The typical response from overworked sysadmins has been to deploy tools like Anubis, which relies on a proof-of-work system to filter out the riffraff. It works, technically. But man, it's a clunky solution that makes everyone suffer.

The Problem with Making Users Suffer

Proof-of-work systems force clients to solve computational puzzles before they're allowed to access content. It's the same energy-guzzling approach that Bitcoin and Ethereum have been criticized for — work that gets thrown away the moment it's completed. For developers just trying to browse a repository or pull some code, waiting for your browser to crunch numbers feels like punishment for being a human.

We've spent decades optimizing web performance. Every millisecond matters. Connection times get squeezed down to their theoretical limits. And then we deliberately introduce artificial delays because bots are annoying? That feels like throwing away all that progress.

What If We Flipped the Script?

Here's where "do-the-work" comes in — a concept that inverts the traditional client-server relationship in a surprisingly elegant way. Instead of the server doing all the heavy lifting while clients coast by, the client actually pays the computational cost of accessing information.

This isn't as crazy as it sounds, especially when you're dealing with Git repositories. Git stores everything as objects — commits, trees, blobs, tags. Every piece of data you see in a Git viewer is just a calculation away from these primitives. If you have the objects, you have everything.

The Client-Side Git Viewer Revolution

The brilliant part about this approach is that modern browsers are absolutely capable of doing this work. A developer named legoktm built a fully client-side Git repository viewer that runs entirely in your browser. The server? It's just serving static files — bare repositories over HTTP. No CGI scripts, no database, no complex backend. Just Apache with some rewrite rules.

The browser downloads objects as needed, stores them in IndexedDB, and computes diffs, file contents, and commit logs locally. It's essentially performing a partial git clone on-demand, backfilling missing objects as you browse. The server's job becomes almost laughably simple — just serve files.

Why This Matters for Developers and Startups

If you're running a startup or managing a small development shop, this approach has some serious advantages:

Bandwidth becomes your only real concern. Since you're serving static content, you can slap a CDN in front of it without any headaches. Your repository viewer becomes virtually infinitely scalable with almost zero backend complexity.

Privacy gets better almost for free. Once your browser has cached the objects, subsequent visits don't need to fetch anything if nothing has changed. You could theoretically browse a repository fully offline after the first load. No server tracking your browsing habits through pagination requests.

Deployment gets absurdly simple. Static hosting works everywhere. GitHub Pages, Netlify, Cloudflare Pages, or even a basic object storage bucket — your Git viewer becomes infrastructure that practically manages itself.

The AI Coding Connection

Here's where this gets interesting for the vibe coding crowd. As AI-assisted development tools become more prevalent, we're going to see more code being generated, more repositories being created, and more demand for lightweight hosting solutions. Systems like this point toward a future where your development infrastructure doesn't need to be a complicated managed service — it can be simple, static, and surprisingly powerful.

The computational power in a user's browser is essentially free computing you can tap into. Instead of paying for server-side rendering, you're harvesting client-side compute. For high-traffic public repositories, this could represent a massive cost savings.

Is This the Future?

It's still early days — consider this a proof-of-concept that shows what's possible rather than a production-ready solution for everyone. But the core idea is sound: make the client do the work, and the server can stay lean and mean.

For Git hosting specifically, if you don't need the full forge experience — issue tracking, pull requests, CI/CD — and you just want to browse code, this approach could replace cgit installations with something far more scalable and privacy-respecting.

The next time you're thinking about how to protect your services from scrapers without making life miserable for legitimate users, consider the do-the-work approach. Your users' browsers have spare cycles. Your servers have limited resources. Let the browsers do the math.

Sometimes the best way to solve a scaling problem isn't to throw more server power at it — it's to distribute the work to where the compute already exists.