Then I built an alternative using free Cloudflare Worker
https://github.com/est/req4cmt
It's a simple service that transform comment POST form data to JSON, append to a .jsonl file, then do a `git push`
It renders comments by `git fetch` from a .jsonl file from a remote repo, or simply via raw.githubusercontent.com if your repo was hosted by Github.
The advantange over Github issue/discussion based comment plugins:
1. All data is stored a .git
2. no login of any sort
Github OAuth login might leak all your repo data along with your `access_token` to the plugin provider.
The `git push` works for any remote. You can choose github/gitlab or whatever.
You now have a direct way for users to insert data into your repo, which can include illegal things. And if you're required to delete it later, you'll be forced to edit your git history.
But if everyone behaves, it's a great solution
Yes, and spam is also a huge concern.
I plan to mitigate by adding "Pull Request" style moderation next.
And you can switch to a private repo
For mass moderation, just git clone, grep the lines, sed them out, and `git push -f`
Remember the use case is for static generated personal blogs.
I'd argue it's even quicker than, say a paginated bloated megabytes javascript rendered single-page application moderation system.
I did try to implement partial-clone but failed
Let's be honest, for a personal blog, >1k comments is an overestimate.
It is painful for writing, but reading comments is quite fast and 99% is about loading.
They certainly do, but for they same reason why people chose static site generators like Hugo over Wordpress, I'd like complete control of full data.
The good value of static-hosted comments is that you `git clone` for backup and `git push` for redudency.
I also dislike managing DBs. Think of all those mess with backups, migrations, imports, exports, difference between mysql/pg/sqlite/d1. Tons of operating cost just for the sake of few blog comments
It's just a bunch of .jsonl files, the last resort is direct inline those .jsonl into .html files when generating
In case of comments you don't like, just delete the line and `git commit`
to erase the history entirely, use `git cherry-pick` and `git push -f`
It might be a nightmare for people not familiar with `git`, but for folks running a static blog like Hugo, they use lots of shell commands anyway.
isn't that better IF the commenter has a GH account? (if you're writing a personal tech blog, then it's not a problem, your readers are Github users already)
Maybe, maybe not. Before 2024, my blog got <10k views/y. Then in 2024 it got close to 1 million (this year it will likely be 100k). Very hard to predict traffic thanks to hn and stuff!
Github issue or discussion based plugins require OAuth
If you look closely, some OAuth scope requires "Act on your behalf". Others require "repo" scope which means read your private data.
Allowing force-push is considered an antipattern for Git, and generally best avoided. It's a safeguard against lost history and prevents data loss.
That aside, the comments are the history. Git is the wrong tool for the job. Why would you choose a generic version-control system designed for source code diffs & merges for the specialised task of chronologically-ordered comments? A database such as PostgreSQL is a far superior choice in just about every possible way. I admire your ingenuity here to make something out of what's available, but I respectfully disagree with this being a good way to capture user-generated content when there are better alternatives.
you mean other files will bloat the repo and slow down the performance? Yes it's a very valid concern, but this system targets personal blogs, which I assume had very few comment traffic.
> Git is the wrong tool for the job ..... A database ... is a far superior choice in just about every possible way
the same argument applies to Wordpress.
But most tech people are choosing static generated blogs anyway, and with git too. File system is the database.
And there are good reasons for that.
I still wouldn't put them into Git along with the rest of the site, that's a definitely no-no. A separate Git? Also no for me. Filesystem does seem viable on reflection, and I feel inspired to explore this now.