Three Layers of Post Editing in atproto: A Case for History-Preserving Design

1. Overview Post editing already exists across the atproto ecosystem. Bluesky's official AppView has not implemented it yet, but third-party clients (deck blue, Skeets, and others) offer editing through client-side workarounds, and the independent AppView tomarigi has integrated editing with its own semantics. logandupont's Discourse proposal — "v1 frozen plus an outdated badge" — reframes these as a Bluesky AppView design problem (https://discourse.atprotocol.community/t/modeling-edits-for-the-big-bsky-edits-release/856). This essay distinguishes three implementation layers of post editing and argues, from the standpoint of misinformation containment, the direction the Bluesky AppView should take.
2. Definitions Implementation layer: Edit implementations in atproto differ by which layer holds and exposes history. This essay identifies three. Layer 1 (client-side editing): Editing expressed entirely on the client, leaving the Bluesky AppView contract unchanged. The client either overwrites the app.bsky.feed.post record via putRecord or inserts an edit note in the body. deck blue and Skeets sit here. Layer 2 (independent AppView): An AppView other than Bluesky's that handles editing with its own semantics. holybea's tomarigi belongs here. It runs on the same atproto, but edit display and interpretation are closed within that AppView. Layer 3 (Bluesky AppView editing): The Bluesky AppView itself implementing edit semantics. logandupont's proposal sits here. Versioning, interaction attribution, and visibility policy are all defined as Bluesky AppView rules. History visibility: The property that a reader can reach the pre-edit record from the post-edit record. Not the mere presence of an "edited" flag: the question is whether the reader can actually view what the post said before. Misinformation containment: The property that an author's correction reaches downstream readers after the original has propagated through quotes and replies. On Bluesky today, the only available tool is delete-and-repost, which severs the propagation chain and leaves the correction stranded.
3. Propositions P1: History visibility is a necessary condition for misinformation containment. If the pre-edit version is invisible to readers, fact-checkers cannot verify what was corrected, and the credibility of the correction itself collapses. Silent edits do not counter misinformation. P2: Layer 1 editing is incompatible with Layer 3. When the client calls putRecord, the Bluesky AppView retains only the latest CID. The pre-edit version becomes invisible network-wide. If the Bluesky AppView later implements history-preserving editing, the history of posts already edited at Layer 1 cannot be recovered. P3: Layer 2 editing does not reach Bluesky AppView users. tomarigi users see the edit model among themselves, but readers viewing the same record through the Bluesky AppView see none of tomarigi's edit semantics. P4: The Bluesky AppView's implementation choice becomes the de facto standard, by market power. Whatever edit model the Bluesky AppView adopts becomes the reference point other AppViews and clients must engage with to claim "Bluesky compatibility."
4. Corollaries C1 (from P1, P4): The Bluesky AppView should adopt Layer 3 editing with history visibility. Because the Bluesky AppView's choice becomes the ecosystem-wide standard for editing, whether that standard supports misinformation containment determines the self-correcting capacity of the entire atproto information ecosystem. C2 (from P2): Posts edited at Layer 1 before the Bluesky AppView ships Layer 3 will carry unrecoverable history gaps. Whether to accept this qualitative split between pre- and post-release posts, and how to design compatibility with existing Layer 1 implementations, are questions the release must address explicitly. C3 (from P1): In the v1-frozen-plus-outdated-badge design, the badge must render inline on quote-post embeds. If the badge appears only on the v1 record page, readers reaching v1 through someone's quote will miss the correction signal, and downstream propagation of the error continues unchecked. C4 (from P3, P4): The successor pointer in Layer 3 editing should be documented as an opt-in convention other AppViews can reference. Not a protocol-level mandate: a product choice by the Bluesky AppView, published as a public convention. Without documentation, every AppView will invent an incompatible scheme of its own.
5. Open Questions How should existing clients providing Layer 1 editing behave once the Bluesky AppView introduces Layer 3? Continue Layer 1 in parallel, migrate to Layer 3, or run a hybrid? At what granularity should history visibility be offered? Step-by-step diff display imposes high cognitive load on readers. Showing only the first and latest versions loses the intermediate revision history. Where is the optimum between fact-checking utility and reader experience? For the successor pointer as opt-in convention, what level of adoption counts as "enough"? Does the Bluesky AppView plus a handful of major third-party AppViews suffice for misinformation containment to function, or must the long tail of AppViews adopt it too? What is the relationship between editing and deletion? Which corrections belong to editing and which belong to deletion? When a post that has been edited is deleted, should pre-edit versions be deleted as well, or preserved?

Discarded Hypotheses

• Editing should be designed for author convenience: Author convenience is a secondary value. In a propagation-heavy network, misinformation containment is the more essential one.
• The edit model should be bindingly enforced network-wide: In atproto, lexicon-level bindingness is reserved for the protocol itself. Everything above is product choice, and an opt-in convention is the appropriate framing.
• Bluesky should take independent AppViews like tomarigi as reference implementations: Layer 2 editing is closed within its AppView and does not transfer to Layer 3. The implementation layers differ, and so do the design constraints.