Skip to main content

ADR-0009 — A social feed, firewalled from the guidebook

Date2026-08-18
Supersedes—
Superseded by—

Context​

The roadmap previously carried an explicit "deliberately not" entry for a feed, and principle 5 argued that partner tagging exists for the accuracy of a record rather than for engagement. Both were written at a point when the product was a guidebook you read.

That position has been reversed by decision: a feed is wanted, in the Strava sense — you see what the people you follow climbed, you react to it, it is a reason to open the app on a Tuesday when you are not going climbing.

The reversal is worth recording rather than quietly editing, because the original reasoning was not baseless. A feed introduces an incentive that a guidebook does not have: content that gets engagement is content the product wants more of. Applied to a guidebook, that incentive is corrosive — it ends with popular crags ranking above accurate ones, and with safety information competing for attention against photographs.

Decision​

We are building a feed. Following, ascents, sessions, reactions, comments, and expiring crag conditions posts. It ships as a tab.

Nothing in the feed may influence guidebook data, and nothing about safety may be engagement-ranked. These are the terms of the decision, not implementation detail.

Concretely, the wall:

  • Engagement never feeds back into the guidebook. Reactions, comments, follower counts and view counts have no input into a grade, a star rating, search ranking, or what a crag screen shows. Grade and quality consensus comes from logged ascent opinions (principle 7) and from nothing else.
  • Safety information is never ranked. Access restrictions, bolt condition reports and route condition reports surface because they are relevant to where you are and what you have downloaded. They are never ordered by popularity, never collapsed behind a "show more", and never competing with a photograph for a slot.
  • Follow, not friend. An asymmetric follow graph, so there is no accept/reject obligation and no implied mutual relationship.
  • Location is not public by default. A tick names a route and therefore a crag; a session in progress does not broadcast where you are standing. Anything real-time is opt-in per post.
  • The feed is not required. The app is fully usable, and every guidebook feature works, for someone who never opens the tab and follows nobody. The feed does not become the route to any guidebook function.

Consequences​

What gets harder:

  • Moderation obligations arrive with comments. User-to-user text means reporting, blocking, muting and a human on the other end of an abuse report. That is a standing operational cost, not a feature, and it is separate from the guidebook moderation queue in roadmap phase 7.
  • Two ranking systems have to stay separate in the code, not just in the docs. The temptation to reuse "what is popular" as a general-purpose sort is exactly the failure this ADR exists to prevent. Expect to say no to it more than once.
  • Privacy becomes a first-class design surface. Defaults have to be settled before the first post exists, because retroactively making content less visible is a promise you cannot keep.
  • It raises the stakes on identity. A feed with no durable account is not a feed. This is now another thing blocked on superseding ADR-0007.

What we are committed to: a follow graph and a post store are additive to the schema, but they are the first tables in the product whose contents are neither guidebook data nor a personal record. They sync on different rules — a feed does not need to work in airplane mode the way a topo does — which means a second, weaker consistency model living alongside ADR-0004.

How we would reverse it: removing the tab is easy. Removing the social graph after people have built one is not, and deleting content people posted is a data-protection exercise rather than a migration.

Alternatives considered​

Keep the "no feed" position​

The original argument: a guidebook that becomes a social network stops being a good guidebook, and the market already has climbing social products. Rejected because it treats the two as the same system. They are not, and the wall described above is what keeps them apart. The risk is real; the answer is the firewall, not abstinence.

A feed that is only your own history​

A private timeline of your own climbing, with no following and no reactions. Genuinely useful and much cheaper. Rejected because it does not do the thing that was wanted — finding out your mate sent their project without either of you texting about it — and because the logbook already serves the private case.

Engagement-ranked, like everything else​

Rank the feed, and let signal from the feed improve the guidebook: popular crags surface first, well-liked photos become the default topo. Rejected outright. A topo is chosen for how well it shows the lines, not for how good it looks, and the day a grade moves because of a reaction count is the day the app stops being trustworthy.

Open questions​

  • Default visibility. Public, followers-only, or private, and whether that differs for a tick versus a session versus a conditions post.
  • Comments at launch, or later. They carry most of the moderation cost and least of the value.
  • What a session is, precisely — a day, a crag visit, or a user-started and user-ended thing. It matters because it is the feed's main unit and also the fastest way to log.
  • Whether conditions posts belong to the feed or to the crag. They read as social and function as guidebook data, which puts them awkwardly astride the wall this ADR draws.