Publications often have multiple contributors like, staff writers, guest columnists, one-time collaborators. On a traditional platform, adding someone to the masthead is trivial. Substack could implement this in an afternoon (and they have). They control the database. Authorization is just a row in a table.
Decentralized publishing does not have that luxury. Data lives across multiple repos controlled by different parties. Authorization must be publicly verifiable without relying on any single application. When a writer leaves a publication, their content must remain theirs while the publication retains its editorial record. A simple feature becomes a protocol design problem.
While I am a core team member of Standard.site, this post does not represent the official position of the project. I am exploring these ideas as part of my research for Offprint a publishing platform I am building on AT Protocol and more specifically as a response to the following post by @tylerjfisher.com:
@standard.site realizing that this really needs an author lexicon. Documents should be able to have multiple authors. Authors should have names and optionally a strong ref to an atproto identity.
Which is proposing a new site.standard.author lexicon definition to allow documents to reference authors.
This leaflet proposes a solution for how publications and authors can establish verifiable relationships, separating contributor access from document acceptance to ensure writers retain ownership while publications maintain editorial control.
To make this work, we need to consider four things: permissions, verification, ownership, and persistence.
Permissions
The first consideration is access control. A publication needs to declare who can contribute, but that declaration must be publicly verifiable. In a centralized system, the platform is the authority. In a decentralized system, the authorization relationship must exist in the data itself.
We solve this with contributor records. A publication maintains a list of authorized contributors in its own repo. Each record includes the contributor's DID and their role. When a document claims association with a publication, any AppView can verify the claim by checking whether a corresponding contributor record exists on the owners PDS/collection.
This mirrors how Bluesky handles lists and labelers. The authorizing party maintains the list. The AppView validates at index time.
Verification
Authorization and acceptance are different concepts. A contributor record answers "can this person submit work?" An acceptance record answers "is this specific document officially part of the publication?"
The distinction matters for guest contributors. A publication might invite someone to write a single article. They need temporary authorization to submit, but the article itself should remain part of the publication permanently. Conflating these creates problems when access changes.
The solution is a separate acceptance lexicon. When a publication accepts a document, it creates a record pointing to that document's AT URI. This record is independent of contributor status. Revoke the contributor, the acceptance persists.
Ownership
Documents live on the author's repo. This is non-negotiable for data sovereignty. Writers keep their work regardless of their relationship with any publication.
The publication field on a document is a claim, not a fact. The document says "I belong to this publication." The publication's acceptance record says "we confirm this document is ours." Both must exist for the relationship to be valid.
This bidirectional confirmation prevents unauthorized claims. Anyone can set a publication URI on their document. Without a matching acceptance record, the claim is unverified. AppViews can filter accordingly.
Persistence
The architecture must handle relationship changes gracefully while preserving editorial integrity.
When a contributor is removed, their previously accepted documents remain in the publication. The acceptance records persist. The contributor record is deleted. New submissions are no longer authorized, but existing work stays. When a publication dissolves, documents remain on author repos. Authors retain their work and can republish elsewhere.
Acceptance records should use a strongRef rather than a standard ref. A strongRef includes both the AT-URI and the CID, locking the reference to a specific version of the document. This preserves exactly what the publication endorsed at the time of acceptance, not whatever the document contains after subsequent edits.
PDSes do not store historical versions. When a document is updated, the previous version is gone. AppViews must fetch the current record, compare its CID against the strongRef, and reject the content if they differ. There is no fallback. Publications that want to guarantee access to accepted versions must archive documents at acceptance time on their own infrastructure.
When an author deletes a document, the acceptance record points to nothing retrievable. AppViews should remove these from active indexes. Publications can retain orphaned records for audit purposes or delete them based on their data retention policies.
Closing Thoughts
This is not a final spec. It is a starting point for discussion. The core insight is that contributor access and document acceptance are separate concerns that require separate records. That separation is what makes the rest of the architecture possible.
I will be implementing this for Offprint over the coming months. If you are working on similar problems or see gaps in this proposal, I would love to hear from you.
📢 Keep in mind that while the implementation may differ in the end, the four core considerations (permissions, verification, ownership, and persistence) are the important part.
I also want to thank everyone who contributes to Standard.site. For those exploring new features, my suggestion is to experiment locally in your own lexicon namespace first. Once you have something working, propose it to the wider community. Convergence on common implementations happens naturally when people have seen what works. Standards emerge from successful experiments, not the other way around.
Thank you for reading,
- Miguel (@aka.dad)