Written in Go. Runs on SQLite. Authors own their files. Forever.
Forty-two years ago, I started with an Amiga 500 and no manual.
Last week, I shipped ForgeCrowdBook — a platform where books live on Codeberg, GitHub, or IPFS, and the community pins what gets featured. No database server. No password hell. No platform lock-in.
Here's the idea — and here's where I need your help.
The Problem with Publishing Platforms
Every writing platform eventually becomes a gatekeeper.
Either an algorithm decides what gets seen, or an admin team moderates what exists, or a VC-backed company decides the rules change next quarter. Authors pour their work into systems they don't own.
Take WordPress. It powers 43% of the web and it's genuinely impressive — but running it means: a PHP server, a MySQL database, a caching layer (because otherwise it's slow), a plugin for security, a plugin for backups, a plugin for SEO, and a hosting bill that grows with traffic. Your content lives in a database you probably don't back up often enough. When the host goes down, your book goes down.
Or you go with Medium, Substack, or Ghost — until the terms change, the algorithm buries you, or the company pivots. Your audience was never really yours.
I've watched it happen. I've experienced it. I wanted something different.
How ForgeCrowdBook Works
You write first. That's it. No repo setup, no IPFS pinning, no technical hurdles before you've written a single chapter.
Here's the actual flow:
- Sign up via Magic Link — no password, no form hell.
- Write your book directly on the platform. Chapters in Markdown.
- Your book appears in "New Releases" — visible, readable, pinnable.
-
The community pins it. Once it hits the threshold (
min_pins, default: 3), you get an email: "Your book made it — here's your ZIP, here's a guide to set up a repo." - You create a repo on Codeberg, GitHub, or IPFS and register the URL.
- Your book goes live on the main page. From that point on, we only store the link — never the file.
The technical bar comes after the creative win. You only need a repo because your book earned it.
Two flavours of books:
- Closed books — only the author adds chapters. The community pins the book.
-
Open books — any registered user can add chapters. Once a chapter reaches
min_pinslikes, the book gets featured.
No admin. No algorithm. The community decides.
The Tech Stack (Intentionally Boring)
Language: Go 1.23+
Database: SQLite (embedded via modernc.org/sqlite)
Auth: Magic Links only — no passwords
Config: SML (our own simple markup language)
Why Go + SQLite? Because boring infrastructure means I can think about the actual problem.
Single binary. Single file database. Runs on a €5 VPS. No Docker required unless you want it.
Auth is Magic Link only — no password resets, no "forgot password" flows, no bcrypt debates. Just click the link in your email. Done.
Performance: Everything is Static
Here's what makes ForgeCrowdBook genuinely fast: there is no dynamic page rendering.
The reading experience is pure static output. Markdown files served from Git forges or IPFS — no PHP, no template engine crunching on every request, no database query per page load. A reader opening a book chapter gets a file. That's it.
Compare that to a typical WordPress setup: a request hits PHP, PHP queries MySQL, MySQL returns rows, PHP renders HTML, a caching plugin maybe saves it for next time. Four moving parts for one page view. Under load, that stack buckles.
ForgeCrowdBook's architecture under load: serve a file. That's it. Static hosting scales to zero cost and near-infinite traffic. IPFS makes it even more resilient — the more people read, the more the content propagates.
The Go backend handles auth, pins, and discovery. Everything else is static. That's not a limitation — it's the design.
Here's what a book page template looks like:
{{ define "content" }}
<h1>{{ .Book.Title }}</h1>
{{ if .Book.AuthorName }}
<p>{{ t "label_by" }} {{ .Book.AuthorName }}</p>
{{ end }}
{{ if .Book.Prologue }}
{{ markdown .Book.Prologue }}
{{ else }}
<p>{{ .Book.Description }}</p>
{{ end }}
{{ end }}
That's it. No code generator. No build pipeline. No hydration step. Go renders this template once — you get HTML. Fast, cacheable, deployable anywhere. The markdown helper converts Markdown to HTML at render time. The t helper handles i18n. Everything else is just data from SQLite.
This is what performance looks like when you don't add complexity you don't need.
What's Alive Right Now
The platform is running. Two books are already on it:
"The Third Attempt" — a closed book. My own story: 42 years, 3 attempts, an Amiga 500, a Forge 4D framework, and an AI team. For junior developers and everyone still waiting for Godot. Free to read. Free to share.
"2026 – The Rewrite Begins" — an open book. A community rewrite of Orwell's 1984, set in 2026. Because some dystopias need new endings, written together.
Both are pinnable. Both are community-owned. Neither requires an account to read.
What I'm Looking For
This is where you come in.
ForgeCrowdBook is real and running, but it's early. I'm an author and a developer, not a team. I want to build this with the community, not just for it.
I want your feature requests.
What's missing? What would make you actually use this as a reader, an author, or a contributor?
Some things I'm already thinking about:
- Book covers ofc
- Nice theme(s)
- Convert to EPUP (kindle direct publishing)
- Convert to PDF (print on demand like Epubli)
- RSS feeds per book and per author
- IPFS pinning support (add your chapter directly from IPFS)
- Better discovery (tags, genres, languages)
- CLI tool for authors to push chapters without touching the web UI
- Federation — imagine following a book across instances
But I might be thinking about the wrong things entirely. Tell me what you'd build first.
I want beta authors.
If you have something to write — a technical series, a fiction project, an open manifesto — I want to host it. Reach out or drop a comment. Magic Link signup is live.
I want Go eyes on the code.
The codebase is ~2,000 lines of clean Go. If you enjoy reading well-structured Go and have thoughts on architecture, routing patterns, or test coverage — I'd love a code review. Open to brutal honesty.
Why There's No Spam Filter
There isn't one. And it's not an oversight.
Most platforms fight spam with CAPTCHAs, moderation queues, IP blocklists, or ML classifiers. All of that is expensive to build, expensive to maintain, and never quite works.
ForgeCrowdBook uses natural friction at the right moment instead.
Layer 1 — Writing: Anyone can create a book. Zero barrier. Spammers can post — but it only lands in "New Releases". No damage done.
Layer 2 — Community pins: Spam doesn't get 3 pins. Real books do. The community is the filter — no algorithm needed.
Layer 3 — The repo: Only authors who receive the "your book made it" email have a reason to set up a repo. That's real work. Spammers don't bother — there's no reward for them at this stage.
The result: IPFS stays clean. The main page stays clean. No moderator ever had to make a decision.
Anti-spam through system design, not through policing. That's the only kind that scales.
The Philosophy Behind It
No passwords. No admin moderation. No content lock-in. No third parties. No database server.
Every one of those "nos" is a deliberate choice. Complexity is a liability. Every dependency is a future migration. Every admin is a future bottleneck.
The license is libera — a libre license in Esperanto. Because the ideas here belong to everyone.
Try It / Follow It / Build It
- Platform: forgecrowdbook on Codeberg
- Read "The Third Attempt": running live at localhost... soon public
- Feature requests: Drop them in the comments here or open an issue on Codeberg
If this resonates — follow me here on dev.to. I'll be writing about the architecture decisions, the SML config language, the IPFS integration road ahead, and what it's like building publishing infrastructure as a solo dev in 2026.
Built by Art (Adam Art Ananda) — developer, author, Rainbow Warrior. Based in Wittenberg, Germany..
Top comments (0)