Followers can see it: Vibes grew a social graph

Every app that gets shared eventually reinvents the same three tables: friends, requests, blocked. Every generated app used to do it too — its own follow list, its own approval flow, its own bugs, none of it portable to the next app. That era is over: Vibes now has one follow graph, owned by the platform, and every vibe you build can lean on it.

The division of labor is the whole design. The platform owns WHO — follow edges, private accounts, approvals, blocking, the management UI in Settings. Apps own WHAT — which documents an author's followers may see. An app never reads the raw graph to decide visibility, and no app can see or change your relationships beyond what you do inside it.

One field, and your followers can watch

Here's what it looks like from inside an app. Say you've built a festival schedule where people star acts. Making those stars visible to the author's followers is one field on a normal access-function result:

jsif (doc.type === "favorite") {
  if (doc.owner !== user.userHandle) throw { forbidden: "not owner" };
  return { audience: { followersOf: doc.owner } };
}

No grant rows are written. No documents move. The label resolves at read time against the live graph, which buys the two properties an ACL snapshot can never give you: someone who follows you tomorrow instantly sees everything you starred last month, and an unfollow, removal, or block revokes instantly — everywhere at once, including live-updating apps the reader has open. There's mutualsOf for both-directions-only visibility, and the author is always in their own audience.

Our family grocery list was the first app to grow the second sharing verb this enables. It always had exactly one: "add someone," full read-write. Now there are two tiers — members edit, followers watch. Flip "Who can see this list" to Followers and your people get a live read-only view with zero invites. It's the same split every social product converges on, except here it took an afternoon and one field.

The hook, and the words

For the people surface — follow buttons, follower counts, request approvals — apps use useSocial():

jsconst { ready, following, followers, requests,
        follow, unfollow, approve, removeFollower } = useSocial();

Accounts are public by default; private accounts turn follows into requests you approve. Removal is deliberately graded: unfollow (stop seeing theirs), remove a follower (quietly stop them seeing yours), block (both directions, chrome-only — apps never get a blocked list). And one copy rule we enforce on ourselves and on generated apps alike: say "followers can see", never "friends." The relationship is one-directional and the words should say so.

Follows ring the bell now

A social graph nobody notices isn't one. Follow events now ride the platform's notification pipeline: a durable inbox row, the live bell in the app, and the weekly email digest — each layer the same event, worded the same way. Phone push is reserved for the follow that actually needs you now: a follow request to your private account reaches your iPhone, while ordinary new-follower news waits politely in the bell and the digest. When we flipped the emitters on this week we didn't take the deploy's word for it: we drove a real follow between two accounts on production and watched the notification row land about 120 milliseconds behind the edge write.

And this is a floor, not a ceiling. The pieces landing next are built on the same rails: inviting someone to Vibes by email — designed carefully enough that the invite endpoint can't be used to probe who's already a user — and a capability for a vibe's own backend to notify its participants, so the chess app you built can tell your opponent it's their move.

The full semantics — private accounts, revocation, the audience field's composition rules — are in the social graph docs. Build something your followers can watch.