What I ended up with is a version of a static forge - Charm's soft-serve to host the repos and a forked version of the pico.sh pgit static site generator. I added git-bug integration to track issues in the repo and an alternative CLI to git-bug that works better when collaborating with agents.
A static forge site is very resilient to bot traffic because it only renders a limited number of commits, instead of pathologically allowing a near infinite number of URLs for bots to crawl.
https://kilimanjaro.io if you want to see what it looks like.
We are actually facing 2 distinct problems:
- Github is a centralized, controlled git hosting, identity, collaboration platform.
- Bots are attacking any public facing interface.
So maybe the solution is:
- to keep a Radicle node private/behind fences to lower the maintenance/security burden, with eventually access to selected collaborators.
- publish the repos with a static site generator like pgit
Issues and CI are the only lock-in. The latter is legitimate because you're using someone else's CPU, but every developer has the tooling to "git diff" and write comments if we could just agree on a format.
Sure, a little more complicated than “Create Issue”, but not that much for devs. We could even simplify the workflow with e.g. git-issue or something like that, similar to e.g. git-send-email.
git issue init “There is a problem”
git issue push
git issue get 6 # short for issue@{6}