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 and supports the scopes below. 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

Connectors extract data on the user’s behalf because most platforms offer no export. An application that holds its users’ data 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. This lets an application avoid holding the data itself:
  • Trust — the app can show users that their data sits in their own store.
  • Data security & compliance — the app runs no central database of sensitive user data.
  • 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 records to the user’s Personal Server through the Write API. 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. Writes are authorized by a write-scoped grant: an entry of the form write:sleep.daily authorizes writing that scope and nothing else, with the same lifecycle as every grant — user-signed, optionally time-bounded, revocable, recorded on-chain. A write entry never satisfies a read, so an app can write a scope it cannot read back. See Scope grammar for the encoding and the Write API for the flow.

​
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)