What the site
actually does.

§ 01 · Scope

A community platform, not a regulated SaaS.

Immersive Commons is a members-run space at Frontier Tower, Floor 10, San Francisco. Our threat model, per /auth.md and the repo's SECURITY.md, is "community platform with an optional member surface" — not a multi-tenant SaaS handling regulated personal data. We store names and email addresses for account purposes. We are not, and do not claim to be, the system of record for sensitive personal data.

§ 02 · What we collect

Two identity paths, both through Clerk.

1. 01Human accounts. Signing in sets a session cookie via Clerk. Your membership tier (public, ft-member, ai-floor, ic-member, or operator) is stored on your Clerk profile. If you opt in to a public profile, your first name, avatar, and (if you link it) GitHub username become visible per the tier-graded directory rules.
2. 02Agent activity. Every consequential action an agent token takes is written to an activity log attributed to that token and the human it's bound to (readable back at ic_activity_get_recent). Research-query text sent through /api/research/ask is deliberately excluded from telemetry — the route omits the query string from logs by design.

§ 03 · Agent tokens

We never store the plaintext.

Agent tokens (agt_*) are minted at /floor10/agent-console or via the device-code flow documented at /auth.md. The plaintext token is shown to you exactly once, at mint time. From then on, the server stores only a SHA-256 digest, keyed as floor10:agent_tokens:<sha256>. Verifying a request means hashing the inbound bearer and looking up that digest — the plaintext is never written to disk or logs. Each token carries a scope list narrower than your account's tier entitlements, and it is individually revocable without touching any other token.

§ 04 · Where it lives

Vercel is the front door. Our own hardware is the engine room.

Identity verification, session cookies, and the public site run on Vercel. Compute-heavy work — the research RAG index, embeddings, corpus data — runs on Ray's own Tailscale fleet, not a third-party data warehouse. That fleet is reachable from Vercel over an authenticated tunnel for server-to-server calls only; no member request ever touches it directly, and personal devices on the same operator's account are explicitly firewalled off from the IC fleet by network policy. We don't sell data to advertisers or data brokers — there isn't a monetization path in this codebase that would need one.

§ 05 · Your control

Revoke, review, ask.

You can revoke any agent token yourself at /floor10/agent-console, or have the token revoke itself via POST /api/agent/token/revoke. Revocation deletes the KV record — the digest stops matching anything. You can review what an agent token has done on your behalf via the activity log. To ask us to look at, correct, or remove account data, use the channels at /contact.

§ 06 · What we don't claim

No compliance theater.

We do not claim GDPR, CCPA, or HIPAA compliance, or certification under any formal privacy framework — those regimes assume a scale and data-handling posture this project doesn't have. We do not run a paid security program; a reasonable response window for a reported issue is about 48 hours for acknowledgement, not a contractual SLA. If any of that changes — if IC starts handling data that needs a real compliance story — this page gets rewritten before the claim, not after.

§ 07 · Immersive Commons Scheduling · Calendar connections

We read when you are busy. We never read what you are busy with.

Immersive Commons Scheduling is rolling out to members now. If you publish a booking link, you connect a Google Calendar so we can tell a visitor which of your times are genuinely open. Connecting is opt-in, per member, and you can undo it at any time. This section covers the permissions we ask Google for and what each one is for.

1. 01View your availability in your calendars. We call Google's freeBusy endpoint for the window a visitor is looking at. It returns intervals, a start time and an end time, and nothing else: no titles, no attendees, no descriptions, no locations.
2. 02See the list of Google calendars you're subscribed to. We read the id and access role of each calendar, so busy time on your secondary calendars is subtracted too. We do not keep calendar names.
3. 03View and edit events on all your calendars. This permission is for creating the one event for a meeting somebody books with you, with both of you on it and a Google Meet link if your meeting type asks for one, and for updating or deleting that same event when either side reschedules or cancels.
4. 04Your email address. We use it to show you which Google account is connected, so you can see at a glance if it's the wrong one.

The third permission is broader than what we use it for

Google's Calendar API has no permission that means "create and manage only the events this app made." The narrowest one that covers creating, updating and cancelling a meeting is the one whose consent screen reads "View and edit events on all your calendars." So we hold a permission that would technically let us read your event titles. We don't read them, and the code enforces that rather than relying on this page:

We never call events.list. Availability comes from freeBusy only.

A test in our repository fails if our calendar client reaches any Calendar endpoint other than free/busy and the calendar list, or contains a path that could be joined into an events request.

We never keep a calendar's name. A calendar can be called "Therapy" or "Job search" or a lawyer's surname, and the name is sensitive in itself. We keep a calendar's id and access role and drop the rest, and a separate test checks that no calendar name survives into anything we hold.

The rule in one line: we learn when you are busy, never anything about why.

We do not use Google Calendar data to train or improve any model, ours or anyone else's. We do not sell it, rent it, or share it with advertisers or data brokers, and we do not use it for advertising. Nobody at Immersive Commons reads it unless you have explicitly asked us to look at something for you, we are legally required to, or it is strictly necessary to investigate a security incident or a bug you reported.

§ 08 · Where a calendar credential lives

One encrypted row, on our own hardware, and nowhere else.

When you connect a calendar, Google gives us a refresh token: a long-lived credential we use to ask for a short-lived access token later. It is the most sensitive thing this product holds.

It is encrypted before it is stored, using authenticated encryption (Fernet, from the cryptography library). The key lives in the service environment of the machine that holds the database. It is not in our source code and not in any file that syncs between our machines, so a copy of the database alone does not give anyone the tokens.

It lives on one machine we own. Our public site runs on Vercel; the booking engine and its database run on our own hardware on a private network. No calendar credential is stored on Vercel, and Vercel functions have no Calendar access.

We do not store your calendar. No events, no titles, no attendee lists, no free/busy history. Busy intervals are held in memory for the length of a request and in a cache that lasts about a minute at most, then they are discarded.

Tokens stay out of logs and error messages. Our tests check that no failure path puts a token into an error message.

If we cannot decrypt a credential, we fail closed. The connection is marked broken and your availability shows as unknown, so we offer fewer times rather than guessing. We never treat a calendar we cannot read as an empty one.

What we store about a booking

For each confirmed meeting: the start and end time, which meeting type it was, the booker's name and email address, an optional note they typed, the Google Meet or location link, the id of the calendar event, and an append-only history of what happened to it (created, rescheduled, cancelled). The history is append-only on purpose: a record that can't be rewritten is how you can trust it.

§ 09 · Disconnecting

You can take the permission back without asking us.

From Immersive Commons: the Disconnect button next to your connected Google account on /scheduling. It does two things, in this order: it asks Google to revoke the permission you gave us, through Google's token revocation endpoint, and checks with Google that the credential no longer works before it says so. Then it deletes the stored credential. If Google does not confirm the revocation, we delete the credential anyway, because you asked us to forget it, and the page tells you so you can finish the revocation at Google.

From Google: revoke Immersive Commons at myaccount.google.com/permissions at any time, without visiting our site. The next time we try to read your calendar, Google refuses, we treat your calendar as unknown, and your booking link stops offering times. We never fall back to treating it as free.

Either way, we stop reading that calendar. Disconnecting your last connected calendar also takes your booking page offline; you switch it back on at /scheduling after you connect one again. To have us delete your booking records, or to ask what we hold, use the channels at /contact. Meetings already on your calendar stay on your calendar: they are real meetings with real people, and removing them silently would be worse than leaving them.

§ 10 · Google API Services User Data Policy

Limited Use.

Immersive Commons' use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. For the calendar data described in §07:

We use it only to provide and improve the scheduling features you can see: showing your open times, creating the meeting, and cancelling it.

We do not transfer it to others except as necessary to provide those features, for security purposes, or to comply with applicable law.

We do not use it for serving advertisements.

We do not allow humans to read it, except with your explicit consent, for security purposes, to comply with applicable law, or where the data is aggregated and anonymised.

We do not use it to develop, improve, or train generalised or non-personalised AI or machine learning models.

§ 11 · If somebody books you

The booker's details exist to make the meeting happen.

Whoever books a time with a member gives us their name and email address, so the member knows who is coming and the booking can be managed, and optionally a note saying why they want to meet. If an AI agent books on someone's behalf, the request is cryptographically signed and we record which key signed it, so the booking can be traced to something even when the agent has no account with us.

We do not add bookers to any mailing list and we do not sell their details. A booker who wants their record removed can ask through /contact. Everything in §06 applies here too.