#Privacy Spheres

Content Addressing showed how every piece of content on Avatarnet carries its own tamper-proof address. But integrity says nothing about who is allowed to read the content. Not everything in your Artificial Mind should be visible to the world. Some things are for everyone, some for specific people, and some for nobody but you.

Avatarnet solves this with three privacy spheres. Every engram belongs to exactly one sphere, chosen by the author at the time of writing.

#The Three Spheres

#Public

Public engrams are visible to anyone on the network. They are stored in plaintext, copied freely across the network, and discoverable by anyone. Your published writings, your wiki pages, and your public bio all live here.

Protection for public content comes not from encryption but from the two guarantees you have already seen: content addressing proves the words have not been altered, and SLH-DSA signatures prove you wrote them. Anyone can read the content, but nobody can change it or forge authorship.

#Private

Private engrams are encrypted and shared with specific recipients. The machines that store and copy them hold only an encrypted blob they cannot read. Only the people the author has chosen can decrypt and access the content. Private messages, shared family history, and notes for a trusted circle all belong here.

#Personal

Personal engrams are encrypted with a key only you hold. They are not advertised or discoverable by anyone on the network. Your drafts, your journal, and anything you are not ready to share stay in this sphere.

The network can still back them up as encrypted blobs, the same way it backs up private engrams, so your personal data survives a hard drive failure. But nobody else receives a decryption key, so the machines that store the backup cannot read a word.

#How Encryption Works Per Sphere

Each sphere uses a different combination of the algorithms covered in the Signing and Encryption page. The reader already knows these algorithms by name, so this section focuses on when each one fires.

#Public: No Encryption

Public content needs no encryption. The engram is stored as plaintext, signed with the author's SLH-DSA private key, and fingerprinted with SHA-512. The machines that host it copy the plaintext along with the signature and the content hash.

Author writes a public engram:

  1. SHA-512(content)                   → Content address (CID)
  2. SLH-DSA sign(CID, private key)    → Signature

Anyone can:
  ✓ Read the content (it is plaintext)
  ✓ Verify integrity: SHA-512(content) == CID
  ✓ Verify authorship: signature valid for author's public key

Nobody can:
  ✗ Change the content (hash would change)
  ✗ Forge authorship (would need the private key)

#Private: AES-256-GCM + ML-KEM-1024

Private content is encrypted with AES-256-GCM. A fresh random encryption key is generated for each engram, so revoking access to one engram does not affect any other. The encryption key is then wrapped individually for each intended recipient using ML-KEM-1024, the post-quantum key encapsulation mechanism from the cryptography section.

Alice writes a private engram for Bob:

  1. Generate a random AES-256 key (unique to this engram)
  2. AES-256-GCM(key, content)          → Encrypted blob
  3. ML-KEM encapsulate(key, Bob's public key)  → Wrapped key for Bob
  4. SHA-512(encrypted blob)            → CID
  5. SLH-DSA sign(CID, Alice's key)    → Signature
  6. Publish: [encrypted blob + wrapped key + CID + signature]

Bob receives:
  1. ML-KEM decapsulate(wrapped key, Bob's private key)  → AES-256 key
  2. AES-256-GCM decrypt(key, encrypted blob)            → Plaintext

The machines that store it can:
  ✓ Verify integrity: SHA-512(blob) == CID
  ✓ Verify authorship: signature valid for Alice's public key
  ✓ Store and copy the blob to other machines

The machines that store it cannot:
  ✗ Read the content (no decryption key)

Adding a second recipient does not require re-encrypting the content. The same AES-256 key is simply wrapped again for the new recipient's public key. Each recipient unwraps the key independently with their own private key.

#Personal: AES-256-GCM + Local Key

Personal content uses the same AES-256-GCM encryption, but the key is wrapped only for the author. The wrapped key lives on the author's device, protected by Argon2id key derivation from the author's password. Nobody else receives a wrapped key. The encrypted blob can be backed up across the network for durability, but without the wrapped key no other machine can decrypt it.

#Selective Sharing

A single Experience can contain engrams in different spheres. "Physics Papers" might hold public engrams for published theories and private engrams for unpublished drafts shared with a collaborator. The sphere is set per engram, not per Experience, so the author has full control over which individual pieces are visible to whom.

This per-engram granularity is why Avatarnet breaks content into small pieces rather than encrypting an avatar as one blob. If the entire avatar were one encrypted file, it would be all or nothing. With per-engram encryption, you can publish your life's work while keeping your journal private, without any structural compromise.

#What the Network Sees

The three spheres create a clear boundary between what is visible to the network and what is hidden.

For private engrams, the CID is computed on the encrypted blob rather than the plaintext. This means the content address itself does not leak information about what is inside. Two identical plaintext engrams encrypted with different keys produce different CIDs.

You now know what Avatarnet stores, how it is organized, who can see it, and what protects it. The next question is how all of this travels across the network: how your device finds other machines, how your data reaches them, and how the network keeps running without a central server. That is the subject of Peer-to-Peer.