A feed that should never feel empty

The forests directory got a new surface this week — a feed of leaves catching disproportionate sunlight across the forests you’re in. You reach it through a small sun-coloured pill at the top of the landing.

The surface · header sort tabs, live ticker, viral cards

A feed of “the most viral things right now” is straightforward at peak times. The harder question is what it shows in the quiet stretches, when nothing actually is.

What you see

A vertical stack of cards, each rooted in a forest and ranked by how quickly a leaf is gathering sunlight. The first card blooms in as the feed loads; subsequent cards stagger. A thin ticker bar at the top cycles through tiny live events — a leaf catching sun somewhere, a new leaf rising — every few seconds.

Each card carries three layers: the forest the leaf belongs to, the root of its tree, and the leaf itself. The shape mirrors the geometry of a tree branching from a root — the visual is the information.

One card · forest pip, root tease, growing spur, branch

When nothing is viral

The first answer is to show the empty state — “no leaves catching sunlight”. That answer is wrong. A surface that vanishes in quiet stretches teaches people not to come back.

The feed falls back through a sequence. When velocity is zero everywhere, it ranks by leaf count — the most-replied threads of the week. When those are sparse, sunlight count — the most-pulled leaves. After that, recency. The label still says “leaves catching sunlight”, because in low-activity moments those rankings are the leaves catching sunlight. The floor isn’t “nothing”; it’s what counts as sunlight when there isn’t much.

The principle

A surface that can be empty will be, sooner than you think — in a new region, on a quiet weekend, after a deploy broke the ingest. The right time to decide what an empty feed shows is before the first reader ever opens it empty.

Tech notes

The feed reads from a Postgres materialized view rather than computing rankings on each request. The view is recomputed every five minutes by a scheduled task and capped at the top two hundred candidate leaves; the API then re-ranks that pool into a top-fifty page for whichever sort the reader picked (velocity, recent, this-week, near-you). Read cost is a single indexed query regardless of underlying activity volume, and refresh runs REFRESH MATERIALIZED VIEW CONCURRENTLY so reads aren’t blocked during recomputation.

The original view definition had two filters that turned out to matter — only leaves between two and six hours old (the velocity window) and only those with non-zero velocity per hour. Either filter is fine on a busy realm; together they silently emptied the view on quiet days. The current definition keeps the velocity window relaxed to seven days and drops the velocity floor entirely, layering the fallback orderings the post describes — leaf count, sunlight count, recency — so the view always has rows. Velocity is still the primary sort when there is velocity; the fallbacks only matter when there isn’t.

Live updates ride a single global WebSocket stream rather than a per-card subscription. The stream is throttled server-side to at most one event per second, and only fires on top-fifty entries, exits, or rank changes of three or more positions — so a viral leaf gathering hundreds of pulls a minute doesn’t fan out to hundreds of messages per viewer. New leaves entering the top fifty trigger a small entry animation; rank changes shift the existing card in place; leaves falling out fade and collapse.

The same view backs a smaller surface in the directory’s search idle state — four trending mini-cards shown when the search input is empty. Same query, smaller limit. One ranking artifact, two surfaces.