Shared Private Data — Explained Simply
Imagine a house party where everyone is in the same room socialising, they're able to gather into groups to have independent discussions but anyone is able to join them. This is how ATproto data exposure functions.
Stratos flips the house party on its head where now we have multiple parties going on in different rooms, each with their own theme (music, fandom, etc.) and the person running the party decides who gets to join. A person could be able to go into any of the rooms or just a subset.
The Problem: Everything Is Public
Social networks built on ATprotocol (like Bluesky) are fully public by default. Every post you write is visible to anyone, anywhere. That's great for public conversations, but it means there's no way to share something with just your group, your community, or your close friends — without leaving the network entirely.
The Stratos Answer
Stratos introduces boundaries — named access scopes that act like club memberships.
When you write a post, you label it with a boundary, like cooking or hiking. Only people who are enrolled in that same boundary can read it. Everyone else sees nothing — not even a hint that the post exists.
Enrollment
Before you can post or read inside a boundary, you enroll with a Stratos service using your existing ATprotocol account. This is a one-time OAuth flow.
When you enroll:
- Stratos checks whether you're on the allowlist (if the operator uses one).
- Your assigned boundaries are recorded.
- A small enrollment record is written to your own PDS (your personal data store on the network), so anyone can discover which Stratos service you're a member of.
Private Data: A tale of two records
When you post something via Stratos, it is stored within the service and never written to your public PDS:
- The full post (with your actual text, attachments, and boundary label) is stored securely inside Stratos.
- Nothing about the post lands on your public PDS. Your enrollment record — published once when you join — advertises your Stratos endpoint so apps know where to look.
- When an app hydrates a post, Stratos returns it with a
sourcefield: a pointer that says "the real version of this lives over here, and you'll need permission to read it".
This means apps can discover and route your posts through your enrollment, but the actual content never leaks onto the public network.
Putting It Together
| Step | What happens |
|---|---|
| You enroll | Your boundaries are recorded; an enrollment record lands on your PDS |
| You write a post | Full content stored in Stratos; nothing is written to your PDS |
| Someone opens your feed | The app hydrates via Stratos, sees the source pointer, gets the full post |
| Stratos checks | Does the requester share your boundary? Yes → full post. No → nothing |
| You see your feed | Only posts from boundaries you're in appear |
Why This Matters
- Your posts live in your namespace (
at://your-did/zone.stratos.feed.post/...), not in a closed silo. - You keep your identity - Stratos is an add-on layer, not a separate account.
- Access control is enforced - When your app fetches a post, Stratos validates the requester's actual boundary membership before returning any content — no trust is delegated to the client.
- Attestations are for discovery, not enforcement - The service attestation in your enrollment record is a public signal: it lets any app confirm that you are enrolled with a specific Stratos service and what boundaries you were assigned at signing time. This enables offline verification without hitting the live service on every request.
Operators choose the rules
A community can run its own Stratos service with its own membership criteria — fully independent of any central authority.