Privacy

What Vibeconferencing stores about you, why, and how to get rid of it. Plain words; the short version is that we keep what the product needs to work and nothing we could sell.

Last updated 12 September 2026. Vibeconferencing is an independent project run by Stan James and Seth Goldstein. Questions and requests: jimmy@vibeconferencing.com.

The two halves

There are two things here, and they hold different data:

• The website (Vibeconferencing at vibeconferencing.com) — sign-in, your account, the shared whiteboards, and the booking page for Call Jimmy.
• The app — a desktop program that runs on your computer and puts a bot in your Google Meet. It drives your own Claude subscription. Almost everything it hears and does stays on that machine.

What the website stores

When you sign in with Google we store your email address, your name and your profile picture URL, plus the Google account id that ties them together. That is what the sign-in scopes (openid, email, profile) provide, and it is all we ask for by default. Signing in sets one cookie, vc_session, which lasts 30 days.

api/lib/db.ts (DbUser) · api/auth/google.ts:54 · api/lib/auth.ts:17

If you tick "calendar access" when signing in — it is off unless you tick it — we also store a Google access token and refresh token for the read-only calendar scope. They are used for exactly one thing: seeing which meetings your bot has been invited to, so it can join on time. We do not read event contents for anything else, and we never write to your calendar.

api/auth/google.ts:61 (calendar.readonly, opt-in) · api/lib/calendar-store.ts:9 (tokens live on the user row)

Whiteboards and rooms. Anything a bot writes to a shared board — the board content and its history (up to 500 versions), chat messages and the lines it speaks — is stored so the room can be reopened later. A room link is a share link: anyone who has it can read the board. Treat it like a shared document, because that is what it is.

api/sync/[roomId].ts:349 (HISTORY_MAX = 500)

Activity. We record when you were last seen on the site, and, if you run the app, its version and platform when it checks in. If an app has remote logging switched on, it also reports its instance id, host, port, current room and call state to an admin-only page so we can tell whether a hosted bot is alive.

api/lib/db.ts (last_seen_at, app_version, app_platform) · api/logs/index.ts:4

Booking a call with Jimmy happens on cal.com, which asks for your name, email and three short answers. cal.com's own privacy policy covers that form; the answers land in the calendar event the bot reads when it joins.

No analytics scripts, no ad pixels. The site does not load any third-party tracking.

What the website does not store

• Audio or video. The website never receives a recording of your call. The app can record locally when its owner switches that on, and that file stays on their computer.
• What Meet captions say. The app reads Google Meet's live captions on the owner's machine to hear the room; that text goes to the owner's own Claude session, not to us — except for lines the bot deliberately writes to the shared board or transcript.
• Model keys or subscriptions. The app uses its owner's Claude account. We hold no model key on your behalf.

How we protect it

This is the part Google's reviewers ask about, so it is spelled out. Every line names the code it was checked against.

In transit. The website is served only over HTTPS. Calls from the app to the website, and from the website to Google, go over TLS. The database connection from the website to Neon is TLS as well (Neon's serverless driver speaks HTTPS).

api/lib/db.ts:8 (@neondatabase/serverless)

At rest. Account rows, including the optional Google calendar tokens, live in a Neon Postgres database, which encrypts its storage at rest. We do not add a second, application-level encryption layer on top of that today; the tokens are columns on the user row, readable only by the website's own server code through the database credential.

api/lib/calendar-store.ts:9 (google_access_token, google_refresh_token, google_token_expires_at on vibeconf.users)

Who can read the calendar tokens. Nobody through the website. There is no page or endpoint that returns a token. The only code that touches them refreshes the access token when it expires and calls Google's Calendar API on your behalf, for your own signed-in session only: the calendar endpoint answers 401 without a valid session and looks up tokens by that session's user id, never by a parameter.

api/calendar/upcoming.ts:36 · api/lib/google-calendar.ts:226

What we read, and how much. One request per poll from your app: events on your primary calendar in the next 24 hours, asking Google for only id, summary, description, attendees (email), Meet link, start, end. The result is returned to your own app and is not stored on the website. Your app keeps a small local note of which events it has already joined so it does not join twice.

api/calendar/upcoming.ts:30 (WINDOW_MS = 24h) · api/lib/google-calendar.ts:161 (fields=)

Sessions. The sign-in cookie is a signed token (JWT) marked HttpOnly, SameSite=Lax and Secure, valid 30 days. Scripts on the page cannot read it.

api/lib/auth.ts:73 (signed with jose) · api/lib/auth.ts:90-94 (cookie flags)

Secrets. Database credentials, the session signing key and the Google client secret are Vercel environment variables, not in the repository. Two people (the founders) can reach that configuration.

Retention and deletion. Calendar tokens are kept until you revoke access at myaccount.google.com/permissions (after which they stop working and we discard them on the next failed refresh) or until you ask us to delete your account, in which case the whole user row goes, tokens included. There is no self-serve "disconnect calendar" button yet; email jimmy@vibeconferencing.com and we do it by hand, normally within a few days.

No model training, no resale. Nothing read from your calendar is used to train any model, shown to any other user, or shared with anyone but Google (who we read it from) and your own app. The AI in the product runs on the app owner's own Anthropic subscription; the website sends Anthropic nothing.

If something goes wrong. If we learn that account data or tokens were exposed, we tell affected users by email at the address on their account, and we revoke the affected Google tokens on our side so they stop working.

Who else touches the data

• Google — sign-in, optional calendar reading, and Google Meet itself.
• Vercel — hosts the website and the room store. Neon — the account database.
• cal.com — the Call Jimmy booking page.
• Anthropic — the model behind a bot, on the operator's subscription, from the operator's machine. The website sends nothing to Anthropic.
• ElevenLabs — only if a bot's owner adds their own voice key; optional.

We do not sell data, and we do not share it beyond the services above.

Your choices

• Revoke Google access any time at myaccount.google.com/permissions. Calendar auto-join stops working; sign-in still works.
• Delete your account or your boards: email jimmy@vibeconferencing.com and we remove the account row (including any calendar tokens) and the rooms you name. We do this by hand for now.
• Sign out clears the session cookie.

Children

Vibeconferencing is not for anyone under 13, and we do not knowingly keep data about children.

Changes

We change this page when the product changes what it stores, and we move the date at the top when we do. Where a claim above cites a file and line, that is the code it was checked against.