Before data can be granted, it has to be collected. Collection always happens on the user’s behalf and under the user’s control — credentials never leave the user, and extracted data lands in the user’s own Personal Server. The Personal Server is the environment that works with the plaintext data; only encrypted files are synced to storage, and the protocol holds just pointers to those files (the Files primitive), never the data or the keys.
Data sources & connectors
Data comes from the user’s accounts on existing platforms — Instagram, X, Reddit, Spotify, and more. Each source has a connector: an extraction script that knows how to pull a given scope from that platform.
Connectors are open source and community-controlled. Anyone can audit or contribute one; they are the part of the system that touches third-party sites, kept transparent by design. Platforms can also build connectors for their own data using their existing APIs to make it easy for their users to port their data into other applications.
Collection paths
| Path | How it collects | Where it runs |
|---|
| Client-side collection | Runs a connector in the user’s app (JavaScript or Playwright) | The user’s device |
| Platform APIs | Pulls data through a platform’s official API where one is available | The user’s app (planned) |
| Server-side collection | Collects on the user’s behalf via ODL-operated infrastructure | ODL-operated infrastructure |
| Continuous feeds | Keeps a source in sync over time, not just a one-time pull | The desktop app |
| Agent / MCP writes | Lets an agent write data into the Personal Server over MCP, not just read it | The Personal Server (planned) |
| Application writes | An application writes its users’ data directly into each user’s Personal Server, instead of storing it itself — see below | The Personal Server (design direction) |
Writing your data to Vana as an application
Connectors exist because most platforms don’t hand their users’ data over — extraction, on the user’s behalf, is the workaround. An application can take the direct path instead: write each user’s data straight into that user’s own Personal Server, and no connector is needed for that data at all.
Why an application would want this: it doesn’t want to be the one holding the data.
- Trust — the app can say, concretely, “your data is right here, in your own store — we’re not doing anything with it.”
- Data security & compliance — no central database of sensitive user data for a subpoena or a breach to land on.
- Sovereignty — each user keeps their own personal data store; when the app needs the data back, it reads it under a grant, like any other builder — and the user can revoke.
Mechanically, the app is building the write side of a connector: it defines a scope and schema for its data and writes files in the standard format to the user’s Personal Server (any client that produces the correct file format can write via the data API — a connector, in this sense, is just the read side of the same contract). From there the data behaves like any other scope: encrypted, synced to the user’s storage, and grantable to other applications — including back to the app that wrote it.
The piece that makes this a first-class flow is a write-scoped grant. Today every grant authorizes reading a scope, and writes happen through clients running under the user’s control. The design direction is a grant that authorizes writing — “this app may write sleep.daily to my Personal Server” — with the same lifecycle as every grant: user-signed, time-bounded, revocable, recorded on-chain.
Status. The write format exists today — scopes, schemas, and the Personal Server’s data API are how connectors already land data. Write-scoped grants are a design direction, not implemented: there is no grant primitive yet for a third-party application to write into a user’s Personal Server.
The Vana apps
Each Vana app is a way for a user to collect data, manage permissions, and host their Personal Server. They differ mainly in how they collect and which Personal Server form they bundle.
| App | Collection | Personal Server |
|---|
| Desktop (Data Connect) | Client-side collection (Playwright) + continuous feeds | Full |
| Web | Server-side collection | Lite |
- App Marketplace — discover apps that request data access
- Memory Visualizer — see what is in the user’s vault
- Personal Server — the embedded access engine (Lite or Full)
