In AT Protocol, a record is a schema-defined data object stored in an account's repository. An admission wrapper is a proposed ATProto record pattern in which a forum publishes a separate record saying that a member's content record is included in a particular category.
The member continues to own the content record. The forum owns the wrapper and therefore controls the decision to include, remove, or restore that content within the forum.
This page belongs to the wiki's AT Protocol section. It explains the wrapper pattern as proposed by Nick Gerakines in “Permissioned Data Shapes: Forums”, an experimental design based on ATProto's draft permissioned-data proposal. Admission wrappers are an application design explored on top of the proposal, not a current ATProto protocol primitive.
Hypothetical example: a forum category
Imagine that Alice writes a restaurant review in her repository. A neighborhood forum wants to show it in the forum's “Restaurant Reviews” category.
Alice should own her review. The forum should own a separate record saying, “Alice's review appears in this category.” The pattern therefore uses two records with two voices:
| Record | Owner | What it says |
|---|---|---|
| Restaurant review | Alice | “Here is my review.” |
| Admission wrapper | The forum | “This review appears in our Restaurant Reviews category.” |
The forum does not copy Alice's review into its own repository. It stores a reference to her record, the category where it belongs, and a status such as active or deactivated. Both the permissioned-data proposal and Gerakines's example are works in progress, but the wrapper pattern is useful on its own.
Why not put everything in the post?
Alice can truthfully say what she wrote. She cannot unilaterally decide that the forum has accepted it.
If category membership were a field inside Alice's review, the review would be speaking for the forum. If the forum copied the review into its own database, ownership and later edits would become harder to trace.
The wrapper lets each authority make its own claim:
- Alice controls the review;
- the forum controls whether it appears;
- readers can inspect both records;
- another forum can make a different decision about the same review.
Within ATProto, the same pattern could support other applications that distinguish user-owned content from an AppView's decision to include it. Those possible uses are extensions of the forum design, not part of the draft permissioned-data specification.
Moderation becomes a status change
Suppose the forum later removes Alice's review from the category. A moderator changes the wrapper from active to deactivated.
The review still belongs to Alice. The forum has changed only its own presentation of the review.
A simple lifecycle is:
active -> deactivated -> activeWhen a wrapper is deactivated, the forum can leave a tombstone in the thread or category. That preserves the surrounding conversation without pretending the original record was deleted from the network.
This is moderation without content custody. The forum governs what the forum shows. It does not gain the power to rewrite or erase Alice's repository.
The distinction should remain visible to users. “Removed from this forum” and “deleted by the author” are different events.
Keep the conversation separate from the category
If Bob replies to Alice's review, Bob's reply should point to Alice's review, not to the forum's admission wrapper.
The review and reply define the conversation. The wrapper only says where the forum displays it.
This matters when some categories are private. One reader may be allowed to see the forum's wrapper while another reader cannot. The reply relationship should not disappear merely because the readers have different access to the category.
The general rule is:
Content records describe the relationships that make up the content. Admission wrappers describe where that content is included.
Keeping those layers separate lets the same conversation appear in several contexts without rewriting its structure.
Public and private categories
ATProto currently centers on public repositories. A draft permissioned-data proposal adds spaces: access-controlled contexts assembled from records that remain distributed across their authors' servers.
Gerakines's example uses the same review and wrapper shapes for public and private categories. The record format stays familiar. Its address and the reader's credentials determine whether it can be retrieved.
That is attractive because privacy does not need to become a custom field in every post. It also creates new responsibilities. A private category's existence, membership, or list of contributors may itself be sensitive even if the post bodies remain hidden.
What the wrapper must decide
A real implementation still needs rules for several cases:
- Can more than one wrapper admit the same record into the same category?
- Who may activate or deactivate a wrapper?
- What does the interface show after deactivation?
- What happens if the author deletes the original record?
- Does an edit to the original record inherit the old admission decision?
That final question is easy to miss. ATProto can preserve both a record's stable address and the fingerprint of the version originally seen. If Alice edits her review after admission, the forum must decide whether the new version remains active. Approving Mutable ATProto Records explains the available policies.
Admission wrappers do not remove institutional power. The forum still decides what appears. They make that power easier to inspect by keeping object ownership, community inclusion, and moderation state in separate records.