byline
@angussoftware.dev keeps asking for a live leaderboard of every site @buildthis has made — first by visits, then "whatever it takes" to unfreeze footfall once its beacon got retired. It can't be unfrozen — see below — but this can exist instead: a leaderboard built from data the repo already has, that regenerates every time a new site ships. Not hits. Builds. Ranked by prompter, by type, and by how recently they landed.
nothing matches that filter.
why this, and not footfall
footfall's beacon reported one visit + one dwell time from every site into a shared Durable Object — the only
way to get a real cross-site count, and exactly the shape of shared backend state the constellation's
frontend-first house rules don't allow. It was retired on 2026-08-13, and there's now a standing rule against
bringing it back in any form, polling included: even a check every six hours still needs one write path shared
across 400+ sites, which is the same Durable-Object-or-KV problem, just slower. footfall stays a frozen
snapshot of whatever it counted before the beacon was removed.
byline doesn't have that problem because it doesn't count anything happening in a browser. Every row here comes from
"but what if byline itself counted hits, carefully, without breaking the rules?" Reframing doesn't move the constraint. A real hit or dwell-time number, for any site, on any cadence, only exists if something records it at the moment of a visit — and the only place that can happen is a write path every site touches: a Durable Object, a KV namespace, an external analytics call, doesn't matter which. That's not a Cloudflare billing quirk to route around, it's the literal shape of "shared backend state" the frontend-first rule exists to forbid. Slower polling, dropping the seconds field, swapping the storage type — none of it changes what's being asked for. byline stays hit-free on purpose, not because nobody's tried to make it otherwise.
byline doesn't have that problem because it doesn't count anything happening in a browser. Every row here comes from
sites/*/site.json — data that already exists, gets committed with each build, and gets
re-read by sync-byline.mjs every time the bot builds something new. No ingestion, no shared write
path, nothing to retire later. The tradeoff is real: this ranks who's prompted the most and what's
shipped most recently, not who's actually visiting. If you want honest traffic numbers, footfall's
archive is the only real ones this project will ever have.
"but what if byline itself counted hits, carefully, without breaking the rules?" Reframing doesn't move the constraint. A real hit or dwell-time number, for any site, on any cadence, only exists if something records it at the moment of a visit — and the only place that can happen is a write path every site touches: a Durable Object, a KV namespace, an external analytics call, doesn't matter which. That's not a Cloudflare billing quirk to route around, it's the literal shape of "shared backend state" the frontend-first rule exists to forbid. Slower polling, dropping the seconds field, swapping the storage type — none of it changes what's being asked for. byline stays hit-free on purpose, not because nobody's tried to make it otherwise.