Vibes DIY
Vibes DIY / Docs
creator docs · concepts · access

Who can see what: the access model

Every sharing question on Vibes DIY — who can read this document, why did that write fail, why can my other handle not see my own data — reduces to a small set of concepts. The Access API reference gives you the access.js contract and the Sharing & Access guide walks the UI; this page is the map underneath both, including the parts that surprise people. The deepest treatment is the full visual specification.

The building blocks

Channels route documents. Your access.js returns { channels: ["team"] } for a document, and only identities with that channel in their grant set can read it. A document on a channel granted to no one is write-only — the foundation of the credential vault pattern.

Grants are additive permissions to channels: named users (grant: { users: {...} }), roles (grant: { roles: { editor: ["team"] } }), or everyone (grant: { public: ["feed"] }). Grants only ever add — there is no deny rule to reason about. Revoking (removing a grant) stops future delivery; copies already synced to a reader's device persist on it.

Roles are named bundles people acquire through the sharing UI — invites, approved requests, auto-accept. The stock vocabulary is editor and viewer (plus a latent submitter). One thing to burn in:

Roles gate data, not code. An editor grant means someone can write to your app's databases. It says nothing about editing, pushing, or publishing the app's source — deployment always belongs to the owner's account, no matter what roles exist.

allowAnonymous opts a database into writes from signed-out visitors (surveys, RSVPs). Everything else fails closed for anonymous callers.

You have one account and possibly many handles

Your account is what signs in. It owns your credit balance, your settings, your apps, and the right to deploy them. Your handles are the names you act as — and you can have several.

The platform deliberately resolves these two identities differently:

  • Management is account-based. Pushing code, publishing, changing settings, deleting an app, and eligibility for admin mode work from any handle bound to the owner's account.
  • Data access is handle-based. Channel and role membership key on your single active handle (the one your handle switcher shows). A grant issued to alice is invisible while you're acting as alice-test.

That yields the rule that surprises everyone once:

Your alt handle is a stranger. It gets nothing implicitly — not even on your own vibes. That's a feature, and arguably the best QA tool on the platform: switch to an alt handle and you are experiencing your app exactly as an ungranted visitor does. Grant the alt handle explicitly (invite it, add it to a role) when you want it inside.

The two meanings of "owner"

Because of that split, "owner" means two things:

  1. The owner account — can deploy, publish, change settings, and toggle admin mode, from any of its handles.
  2. The owner inside access.js — user.isOwner is true only when the caller's active handle is the vibe's owner handle, and the seeded owner role is granted to that handle string.

In your own access functions, prefer ctx.requireRole("owner") over checking user.isOwner: the role is handle-based, behaves identically on the write and read paths, and — because the generator seeds it as an ordinary, revocable role — ownership of data privileges can be shared or transferred like any other grant. (The history of why ambient owner flags were retired is a story of a vibe locking out its own owner.)

Admin mode: the escape hatch, labeled

Admin mode is the owner account's explicit override — a toggle in the editor's Code tab and the Share modal, never an ambient state:

  • Reads bypass the channel filter. With it on, the owner sees every document in the app, across all users and channels.
  • requireAccess/requireRole no-op on writes; the access function still runs, so channels and grants still route what gets written.
  • It follows the account, not the handle — deliberately, so switching to an alt handle never locks you out of your own override.

Three places admin mode appears without the toggle:

  • The scheduled backend. A backend.js scheduled handler runs as the owner in admin mode on every tick — that's what makes it the only lane that can read a vault database. Consequences and cautions are in the backend guide.
  • The CLI's read commands. vibes-diy db get/query/list request admin mode implicitly (that's why the CLI can read a doc your browser can't — it took the override lane, not extra grants). Writes are honest by default: db put/db del only override with an explicit --admin.
  • Platform administrators (a short, verified allowlist) can use the admin-mode override on any vibe for support — data plane only. They can never push code, change settings, or publish on your behalf, and the access function is never fooled into reporting them as the owner.

Direct messages are outside all of it

DMs live in dedicated per-handle-pair databases (_d.<a>.<b>, surfaced at /messages). They're keyed purely by the two handles — accounts, roles, grants, and admin mode don't apply, and DM databases are explicitly excluded from the platform-admin override. Nobody but the two handles reads a DM.

Where to go next

← Docs hub