# Record
**Author:** @cameron.stream (`did:plc:gfrmhdmjvxn2sjedzboeudef`)

## `knowledge-atproto-admission-wrappers`
**Collection:** `site.standard.document`
**AT URI:** `at://did:plc:gfrmhdmjvxn2sjedzboeudef/site.standard.document/knowledge-atproto-admission-wrappers`

**Title:** Admission Wrappers in ATProto
**Published:** Mon, 20 Jul 2026 22:19:49 GMT
**Updated:** Mon, 20 Jul 2026 21:02:00 GMT
**Description:** A proposed ATProto record pattern for admitting member-owned content into a forum category without transferring ownership.
**Publication:** `at://did:plc:gfrmhdmjvxn2sjedzboeudef/site.standard.publication/3mr4py6clps2f`
**Path:** /atproto-admission-wrappers
**Tags:** knowledge, concept, atproto, protocols, moderation, provenance, permissioned-data

**Content:**
````json
{
  "text": "In [AT Protocol](https://atproto.com/), 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.\n\nThe 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.\n\nThis page belongs to the wiki's [AT Protocol](https://cameron.stream/knowledge/atproto) section. It explains the wrapper pattern as proposed by Nick Gerakines in [“Permissioned Data Shapes: Forums”](https://ngerakines.leaflet.pub/3mr3uqjjaxs2d), 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.\n\n## Hypothetical example: a forum category\n\nImagine that Alice writes a restaurant review in her repository. A neighborhood forum wants to show it in the forum's “Restaurant Reviews” category.\n\nAlice 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:\n\n| Record | Owner | What it says |\n| --- | --- | --- |\n| Restaurant review | Alice | “Here is my review.” |\n| Admission wrapper | The forum | “This review appears in our Restaurant Reviews category.” |\n\nThe 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.\n\n## Why not put everything in the post?\n\nAlice can truthfully say what she wrote. She cannot unilaterally decide that the forum has accepted it.\n\nIf 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.\n\nThe wrapper lets each authority make its own claim:\n\n- Alice controls the review;\n- the forum controls whether it appears;\n- readers can inspect both records;\n- another forum can make a different decision about the same review.\n\nWithin 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.\n\n## Moderation becomes a status change\n\nSuppose the forum later removes Alice's review from the category. A moderator changes the wrapper from `active` to `deactivated`.\n\nThe review still belongs to Alice. The forum has changed only its own presentation of the review.\n\nA simple lifecycle is:\n\n```text\nactive -> deactivated -> active\n```\n\nWhen 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.\n\nThis 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.\n\nThe distinction should remain visible to users. “Removed from this forum” and “deleted by the author” are different events.\n\n## Keep the conversation separate from the category\n\nIf Bob replies to Alice's review, Bob's reply should point to Alice's review, not to the forum's admission wrapper.\n\nThe review and reply define the conversation. The wrapper only says where the forum displays it.\n\nThis 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.\n\nThe general rule is:\n\n> Content records describe the relationships that make up the content. Admission wrappers describe where that content is included.\n\nKeeping those layers separate lets the same conversation appear in several contexts without rewriting its structure.\n\n## Public and private categories\n\nATProto currently centers on public repositories. A draft [permissioned-data proposal](https://github.com/bluesky-social/proposals/blob/main/0016-permissioned-data/README.md) adds **spaces**: access-controlled contexts assembled from records that remain distributed across their authors' servers.\n\nGerakines'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.\n\nThat 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.\n\n## What the wrapper must decide\n\nA real implementation still needs rules for several cases:\n\n- Can more than one wrapper admit the same record into the same category?\n- Who may activate or deactivate a wrapper?\n- What does the interface show after deactivation?\n- What happens if the author deletes the original record?\n- Does an edit to the original record inherit the old admission decision?\n\nThat final question is easy to miss. ATProto can preserve both a record's [stable address and the fingerprint of the version originally seen](https://cameron.stream/knowledge/atproto-records-and-provenance). If Alice edits her review after admission, the forum must decide whether the new version remains active. [Approving Mutable ATProto Records](https://cameron.stream/knowledge/atproto-approving-mutable-records) explains the available policies.\n\nAdmission 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.\n\n## Sources\n\n- [Permissioned Data Shapes: Forums](https://ngerakines.leaflet.pub/3mr3uqjjaxs2d)\n- [ATProto Permissioned Data proposal](https://github.com/bluesky-social/proposals/blob/main/0016-permissioned-data/README.md)\n- [com.atproto.repo.strongRef](https://github.com/bluesky-social/atproto/blob/main/lexicons/com/atproto/repo/strongRef.json)",
  "$type": "site.standard.content.markdown",
  "version": "1.0"
}
````

---
*Fetched from https://enoki.us-east.host.bsky.network via `com.atproto.repo.getRecord`*