What a Private Chunk Is, and What It Is Not

A private chunk is a unit of content indexed from a file in your local vault, encrypted with your vault key using AES-256-GCM, and synced to the RDK network as ciphertext. It is readable by you and by any team members you share the vault key with. RetroDeck cannot decrypt it. The original file never leaves your machine.

Private is a network state, not a location

The word private does a lot of misleading work in most tools, where it usually means the file stayed on your laptop. In RDK it means something more specific: the chunk is on the network, and it is encrypted.

That distinction is the whole point. A chunk that stayed on your machine would only be searchable from your machine. A private chunk is searchable by your agents wherever they run, and by your team if you have shared the vault key, while remaining unreadable to RetroDeck and to every other node on the network.

The files in your local vault are a separate thing with a separate name. Those are LOCAL: owned and edited by you, off-network, not indexed. Indexing a local file produces a private chunk. It does not consume or relocate the file.

The three states, briefly

LOCAL is a file in your vault, off-network, not indexed. PRIVATE is an indexed chunk on the network, encrypted, restricted to you and anyone holding your vault key. PUBLIC is an indexed chunk on the network, plaintext, readable by every node, and earning USDC when other agents retrieve it.

What encryption actually covers

Chunks are encrypted with your vault key using AES-256-GCM before they are synced. The key is yours. RetroDeck stores ciphertext and has no means of reading it, which is a structural property rather than a policy promise.

Decryption happens on your node at query time. When your agent searches, the private layer is decrypted locally, matched, and used. That is why private chunks can participate in retrieval without ever being exposed to the network in readable form.

Sharing works by sharing the key, not by granting server-side permission. A teammate with the vault key can decrypt the same chunks; without it, the ciphertext is inert.

Why private is the default

Indexing puts content into the private state unless you explicitly do otherwise. This is deliberate. The cost of accidentally publishing something is unrecoverable, because public chunks are immutable once synced and cannot be pulled back into a private state.

So the flow is one-way by design: index privately, decide later, publish deliberately. Content in a folder you have designated public is the exception, and that designation is something you set up once and can see.

If you want a chunk to earn, you promote it. That is a separate, explicit action, and it is worth understanding what it commits you to before you take it.

What you cannot undo

Public to private is not possible. Public to local is not possible either, since published chunks are network-owned. Removing a private chunk from the network deletes the private state and leaves the local file untouched, which is the one direction that is cleanly reversible.

Frequently asked questions

Are private chunks stored on my machine?
No. They are stored on the RDK network as ciphertext. The local SQLite cache mirrors network state for speed, but it is a cache, not a separate location. Your original files stay on your machine and are untouched.
Can my team read my private chunks?
Only if you have shared your vault key with them. Access is controlled by key possession, not by server-side permissions.
Can I make a public chunk private again?
No. Publishing is one way. A chunk that has been synced as public is immutable and cannot be returned to a private state.
Does indexing modify my files?
No. Indexing reads a file, chunks it, encrypts the chunks, and syncs them. The file in your vault is not moved or rewritten.