{
  "path": "//stratos-lets-get-technical",
  "site": "at://did:plc:lrphxvv25aibthe7xoc2eeyy/site.standard.publication/3mimqtwsxep2r",
  "tags": "post",
  "$type": "site.standard.document",
  "title": "Stratos: Lets get Technical",
  "description": "A deeper look at permission private data with Stratos",
  "publishedAt": "2026-03-22T00:00:00.000Z",
  "textContent": "It's been just over two months since our proposal. Since then there have been quite a few announcements and discussions around private data. Daniels series of posts on Blueskys approach to addressing private data for users with ~~buckets~~ spaces has created even more excitement in this area, combined with AtmosphereConf in less than a week I thought it would be a good time to come back with a form of tech deep dive on how Stratos is approaching private data and permissions.\n\n{% image \"assets/images/stratos-technical-review/private-data-so-hot.jpg\", 'Zoolander Meme of the fashion designed swooning at the fashion show at the end of the movie. Captioned with \"Private Data, So Hot Right Now\"', {\n  align: \"center\"\n} %}\n\nDomains and Boundaries\n\nAs explained in the last post, Stratos is modeled around domains and boundaries. Rather than explaining what those are, let's start with something we all (hopefully) understand, a map:\n\n{% image \"assets/images/stratos-technical-review/domains-boundaries.jpg\", 'A fantasy RPG map showing an island that has been split up into four kingdoms: Spook City, Horok Castle, Goab, and Moldymoor', {\n  align: \"center\"\n} %}\n\nLooking at this map we immediately recognize that this island has been divided into four domains with respective boundaries which define where one ends and another begins, to cross from one to another likely requires specific privileges to do so. To be part of a domain requires a privilege that may be granted freely or require requesting it. we won't get into the nuance of how it works in this map (maybe you need to ride a particular fantastical flying dragon to traverse them) but we envision a community focused approach to private data where rather than thinking how a single person would share content we approach with how a group should be able to share content together.\n\nThis is the essence of how we designed permission data, now for how it works on a technical level? We didn't want to build an implementation that is so custom that it breaks protocol, instead we struck out to build something that is \"protocol adjacent\" in that it is fully compatible with the knowledge that we're keeping data from being exposed. \n\nProtocol Adjacent\n\nUsers data is hosted on a PDS using MST to provide the self verification proofs for data integrity and each user has their own signing key which provides the gurantee that the records in their collection are signed by them, this key is rotated when a user migrates to another PDS. Rather than looking at \"How do we extend the PDS to cover private data\" which leads to maintainability/adoption concerns, we took the approach of \"How do we add a private data store that compliments the PDS\". A dedicated service grants a certain degree of modularity/control where a community operator is able to provide a dedicated service that users can enroll in. \n\nOn ATproto this would ideally be adding the service endpoint to the users DID so it is clearly advertised and trusted however the barrier to updating the document is presently rather high and current controls on the PDS are an \"All or nothing\" where a user has to grant a service full access to their document which is an attack surface we're not comfortable with. Therefore when a user enrolls in the service, an enrollment record is written to their repo containing the service endpoint and an attestation that can be verified. \n\n{% image \"assets/images/stratos-technical-review/stratos-enrollment-flow.png\", 'A Diagram showing how a user enrolls in Stratos. A P256 key is generate for the user to sign their records and a record zone.stratos.actor.enrollment is written to their PDS containing the service endpoint and an attestation signed by the services Secp256K1 key', {\n  align: \"center\"\n} %}\n\nStratos itself uses a Secp256K1 key, when a user enrolls a P256 key is generated to sign all their records in a MST. During the enrollment process a record is written to their PDS repo with the lexicon zone.stratos.actor.enrollment which contains one or more address enrollments at zone.stratos.actor.enrollment/did:web:stratos.service.com. Each enrollment contains the service endpoint, boundaries the user is enrolled in and an attestation signed by the service key containing the service and user did, users public key and their boundaries. This allows any service/user to self verify that they are enrolled in the service and what they can access.\n\nThe enrollment process itself happens via Oauth DPoP where a user grants Stratos acces to write stratos lexicons to their PDS including the enrollment record, and \"stubs\"\n\nAdvertising privacy in plain sight\n\nAs for what these stubs are? We've taken the smoke signals approach with private posts where when a user creates a post a zone.stratos.feed.post record is written to both the PDS and Stratos with a small difference.\n\n{% image \"assets/images/stratos-technical-review/stratos-record-stub-creation.png\", 'A Diagram showing how a user creates a post in Stratos. A zone.stratos.feed.post record is created in both', {\n  align: \"center\"\n} %}\n\nOn the PDS the record only contains the service endpoint and pointer to the record within stratos.\n\nWithin Stratos we have the full details of the record including the boundary it was created with:\n\nBy placing a stub reference record on the PDS, the record is published to the firehose allowing any ATproto service to consume it, recognise it is a private post, and know how to handle it should the developer choose to support Stratos. Via the Oauth flow a user can allow the service to access their private data and hydrate the record to see the full data. \n\nWithin Stratos the service only ever serves a user records they have a shared domain with (a boundary overlap), allowing a single service to host multiple domains and serve different audiences/communities. \n\nThere's a bit more happening within the guts of Stratos and we've worked hard on it since the start of the year to get it to what we would consider a \"alpha beta\" and have now made the code public while we work on implementing the remaining bits and pieces, as a bonus a webapp is included to demonstrate how it all goes together. I'll go over Stratos a bit more at AtmosphereConf and if you'd like to chat more about it while I'm there don't hesitate :)",
  "canonicalUrl": "https://chipnick.com//stratos-lets-get-technical"
}