Skip to main content
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, maintained in the PDP-Connect/data-connectors repository. 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

Server-side collection always lands in a Personal Server before any storage — it is a collection helper, not a place data lives.

​
Server-side collection scope coverage

Server-side collection runs through the ODL Data Pipe. It covers a small set of scopes today. Every other scope is collected client-side. Coverage grows over time. To collect a scope that is not listed, use client-side collection.

​
Writing your data to Vana as an application

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.
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.

​
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. Every app shares the same surfaces on top of the Personal Server:
  • 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)