Trending slates returned
3
New slates returned
3
Spotlights
2
Cache lifetime
1 hour
Cache entries
1
Categories seeded
3,558
The Feed, Stated Plainly
One endpoint returns four things: three trending slates, three new ones, a chip of the day, and two spotlights. It takes no arguments. It is not paginated. It is cached for an hour in a store with room for exactly one entry, which is a fair description of the ambition: this is a front door, not a recommender.
Trending Is Impressions and Nothing Else
The query is named after likes and views. Likes do not appear in it. It counts distinct impression rows per public indexed slate and orders by that count, descending, over all time.
select s from Slate s
left join SlateImpression si on s.id = si.slate.id
where s.visibility = 'PUBLIC' and s.indexed = true
and s.deletedAt is null
group by s.id
order by count(distinct si) desc
No Decay, and a Loop
There is no time window and no half life. A slate that did well once outranks everything after it, indefinitely. And appearing in the feed records impressions for the slates in the feed, which is the exact number that put them there. Being trending makes you more trending. The repository already contains a windowed variant that takes a week start parameter. Discovery does not call it.
New Is Recency With a Cliff
Public, indexed, created within the last seven days, newest first. No fallback, no backfill. If nothing is published for a week the section is empty rather than reaching further back. On a platform this size that is not hypothetical.
The category page uses the same query with ascending order, so a category's New carousel leads with the oldest slate of the past week. That is a bug, not a decision.
Everyone Sees the Same Thing
The service never accepts a user in the first place. Its entry point takes no caller argument, and a guest identity is constructed afterwards purely to attribute impression recording. Combined with a single entry cache, the feed is identical for every visitor by construction, not by accident. There is no personalisation to disable because none was ever built. Whether that is a deficiency depends on whether you think a platform with this much content should be guessing at taste yet.
How well each discovery surface actually works
1 is barely functional, 5 is solid
/
strength
Categories Are Hand Written
Sixteen roots, 477 nodes at the second level, 1,863 at the third, and a long thinning tail that reaches eleven levels deep. 3,558 rows in total, seeded from a single SQL file. Science and Technology, Arts and Culture, Nature and Environment, Animals and Pets, and twelve more. No language model built this tree. A person wrote the tree, and slates are assigned by their author at creation or reassigned by an admin later. It is unglamorous and it is the part of discovery that works best.
The Counts Drift
Each category carries a denormalised slate count, incremented and decremented up the tree on every write. It goes wrong, and the repair is an admin endpoint that recursively recounts the whole tree. Since root ordering on the category list depends on that number, a drifted count quietly reorders the front page of the taxonomy.
Explore Is a Tab, Not a Screen
The Explore surface that shipped on 20 March 2026 is described as a grid of random public chips. It lives as a tab inside the chip catalogue rather than a route of its own. The randomness is also not quite there: the query orders by publish date descending, and the shuffle happens afterwards, on the page that was already fetched. Scroll far enough and you walk straight down the timeline. Shuffling a page you already have adds no diversity, only the appearance of it.
Search Is a Substring Scan
No full text index exists on the slates table. Search is a LIKE with a leading wildcard on the display name, which no index can serve, so every query is a full table scan. It returns twelve results per section with no ordering clause at all: the rows arrive in whatever order the database hands back. Slate The category and chip paths lowercase both sides before comparing; the slate path does not. That asymmetry is real in the code, though it is invisible to users: the table collation is case and accent insensitive, so the match works anyway. It is a latent bug rather than a live one.
select s from Slate s LEFT JOIN s.category c
where ((:name IS NULL OR s.displayName LIKE CONCAT('%', :name, '%'))
AND (:industry IS NULL OR LOWER(c.name) LIKE CONCAT('%', :industry, '%')))
AND (s.visibility = 'PUBLIC' OR (:actingUsername IS NOT NULL
AND s.author.username = :actingUsername)) and s.deletedAt is null
Only the Title Is Searchable
Not the description. Not the chip contents. Not any sub-page. A slate about Norwegian fjords titled Postcards From the North is unfindable by searching for Norway. That single limitation probably costs more discovery than the ranking gaps above it combined.
The Code That Was Written and Never Wired Up
Two queries sit in the repository implementing genuine discovery heuristics. One orders by how many followers a slate has. The other boosts underexposed work: slates with fewer than fifty followers, published in the last thirty days, with the dominant category excluded so one topic cannot fill the feed. Neither has a single caller. Someone thought carefully about exposure balancing, built it, and stopped before the last connection. It is the most interesting code in the module and it has never run in production.
Discovery as it stands
A curated category tree with real depth
A trending list, on an honest but crude metric
A new list, with a hard seven day edge
Search that finds a title you already half remember
Recency decay in trending
Any personalisation at all
Search across descriptions or chip content
The exposure balancing that is already written
"A feed with no decay does not rank work. It ranks whatever got lucky first.
"
