VitaTalk
A nutrition and supplements board that ran on phpBB from 2004 and went quiet in 2010, rebuilt in 2026 with no application server at all: the forum is a directory of JSON files in git - one per thread, member and config - that Astro renders at build time.
Overview
VitaTalk has been a domain since 2004. It ran as a phpBB board about nutrition, supplements and everyday health, went quiet in 2010, and was rebuilt from scratch in 2026 - not as a restored phpBB, but as a static forum with no application server behind it.
The old board came along. Threads from 2005 sit next to new ones with their original authors, dates and replies intact, and 72 member profiles were carried over, so a discussion started 21 years ago still reads as the discussion it was. Six categories organise the board today: supplements and vitamins, nutrition and diet, sports nutrition, healthy aging, sleep and stress, and general health.
The engine treats git as the database. The whole forum is a directory of JSON files committed to the site repository - one file for the forum config and category list, one per member, one per thread with its replies inline - and Astro renders them at build time. A thread being a single file is a deliberate choice: concurrent writes never collide, and every change is a reviewable diff with an author and a timestamp.
Provenance is built into the data model rather than added as a disclaimer. Every post carries one of three labels shown next to the byline - human, assisted or imported - and the label is enforced by the loader, not by editorial habit. Assisted threads must list the dated sources they were drafted from; a declared fictional persona must carry a disclosure and may only author assisted content, so a generated profile can never appear to report firsthand experience.
What was built
- A static forum engine: Astro renders JSON files from the repository into categories, threads, member profiles and the latest and top views; nothing executes at request time.
- A datastore of plain files - forum config and categories, one JSON per member, one JSON per thread with replies inline - so the history of the board is the history of the repository.
- An import of the 2004 to 2010 phpBB board: threads, replies, authors and dates preserved, 72 member profiles carried over.
- Three authorship labels - human, assisted, imported - rendered beside every byline, with dated sources required on assisted threads.
- A disclosure rule for declared synthetic personas, enforced in the loader: no disclosure or a post claiming firsthand experience fails to load rather than quietly publishing.
- Reserved handles that only the server-side generator can use, closing the impersonation hole where a typed display name could adopt an existing identity.
- Publishing plumbing: RSS feed, canonical URLs, WebSite JSON-LD and a sitemap driven by each thread's updated date.
Stack
Frontend
- Astro
- Static site build; categories, threads and profiles are rendered from files
- Hand-written CSS
- Inlined in the page; the board loads without a framework or a client-side router
Data
- Forum engine (TypeScript)
- Typed shapes for forum, member, thread and reply, with the authorship and disclosure rules enforced on load
- JSON in git
- The datastore: one file per thread, member and config; every change is a diff with an author and a timestamp
Infrastructure & DevOps
- Cloudflare Pages
- Hosting for the board and its forum project
Content & SEO
- RSS
- Feed of new threads
- schema.org JSON-LD
- WebSite markup, canonical URLs, sitemap lastmod from thread activity
Engineering highlights
A forum with no server: the usual phpBB stack - PHP, MySQL, sessions, patching - is replaced by files in a repository and a static build, which is why a board that went quiet in 2010 can be back online without an application to maintain.
Twenty-one-year-old discussions were treated as content worth keeping, not as legacy to discard: original authors, dates and replies survived the migration.
Provenance is a data type, not a policy page: the loader refuses a synthetic member without a disclosure and refuses firsthand claims from one, so the rule cannot rot.
One thread equals one file, which removes the write-collision problem that any generated or multi-author pipeline otherwise has to solve with locks.