#Aims and reasoning
#Preserve useful material without turning conversation into a feed
A conversation may produce something people want to keep or share. That should not make every message a publication waiting to happen. §05 requires agreement from meaningful participants on the selected material, audience, retention, and provenance. A local pin leaves access unchanged. A wider publication is a separate act.
The same object foundation can support posts, shared documents, tasks, and community knowledge without merging their audiences. Paths, grids, feeds, and boards are views. Moving a reference between views does not by itself change technical authority, descriptive responsibility, physical ownership, or commitments. An ordinary edit within established authority should not require a formal governance proposal (shared-core integration).
#Authenticity should not create unnecessary public evidence
A recipient needs to authenticate private material to the degree the context requires. That does not imply a public author signature on every message. An intentional attestation to a newly approved artifact is a different claim from proof of who said each earlier sentence. The selected evidence profile must also cover introductions, consent receipts, signed roots, and upload records; otherwise an adjacent record can recreate the proof the payload design avoided (authentication analysis).
Retention is part of the artifact agreement. Revision history should preserve necessary context without retaining withdrawn bodies indefinitely. An old valid checkpoint is not necessarily the current accepted state, and a replica's arrival order must not decide what is authorized.
#Protocol and architecture
#Lifecycle state machine
“Authenticated” uses the context's selected evidence model; it is not a blanket signature requirement. A delayed source, consent receipt, or policy parent leaves the transition pending or quarantined. Concurrency between withdrawal and publication still needs an explicit admission rule. No offline client can promise knowledge of a withdrawal it has not received.
A withdrawn revision is not automatically resurrected by an old replica, backup, or later edit. Any republication needs the current authority and consent required for that act, plus the retention boundary on what may still exist.
#Consent and provenance sequence
Consent may be recipient-local, context-verifiable, or deliberately transferable. Encrypting an ordinary signature limits initial disclosure but does not make the signature non-transferable after decryption. Source event IDs, private conversation references, or identity-linked consent records must not leak through public provenance or cleartext associated data. The new publication can attest present agreement without retroactively attesting private authorship.
#Five identities, not one
| Identifier | Meaning | Required boundary |
|---|---|---|
object_id | Logical post, record, document, or attachment | Scoped identity, not a global content or person index |
event_id | One authenticated change or control action | Evidence class is explicit; a transferable personal signature is not universal |
revision_id | One immutable revision or accepted checkpoint | Byte integrity does not establish freshness or social adoption |
projection_id | A local or shared-purpose view | Adding a view does not grant new readers |
ciphertext_id | One encrypted representation or its byte locator | Reuse can reveal equality; it is not the logical object's authority |
IDs exposed outside their intended context need separate scope review. Private display deduplication can recognize accessible references without publishing a common equality marker between unrevealed spheres.
#Promotion and encryption boundary
The exception requires an already object-encrypted source whose policy and authenticated binding permit reuse. It cannot export an MLS or ratchet session secret. Changed context, audience, retention, authentication binding, or unlinkability requirements normally require a new representation. Rewrapping the old key neither removes access from old key holders nor conceals that the ciphertext is the same.
A large encrypted payload can be stored once inside its intentional sharing domain and served to several readers through small protected descriptors. Storage hashes verify bytes; descriptors carry keys and context binding; the selected relationship/group mechanism authenticates the share. The encryption page owns that composition.
#Replies are children with an audience ceiling
A separate reply file does not widen its parent. The effective audience is the parent discussion scope intersected with the commenter's choice and applicable grants, as owned by §06. Bind the thread root, parent revision, context, and relevant policy evidence inside protected authenticated fields. A parent-policy change must not silently rewrite historical consent or issue new old-content keys. Referencing a withdrawn parent can preserve context without restoring its body.
#Event families
| Sketch | Records | Does not establish |
|---|---|---|
message.commit | Authenticated conversation revision | Publication consent or public personal-authorship proof |
pin.reference | Local reference | New keys, audience, or remote retention |
publication.propose | Selected material, target, retention, and provenance request | Its own authorization |
consent.receipt | Agreement under a declared evidence profile | Unrelated governance or moderation powers |
publication.commit | New representation and reader/key policy | Relay authority or remote deletion |
reply.commit | Parent revision and bounded scope | Wider disclosure |
record.change | Authorized shared-record operation | Physical ownership or collective endorsement merely from entry |
checkpoint.adopt | Current endorsement of a shared state | Independent proof of every historical contributor |
moderation.overlay | Scoped hide, label, quarantine, appeal, or withdrawal | Erasure of delivered plaintext |
These are schema sketches. Personal blocks, private modes, and local references need not become replicated protocol events.
#Variation — Explicit object and event core
This is the narrower first-slice candidate from the tools inventory. It makes the application object contract explicit, but requires implementation of validation, accepted-history rules, migrations, and recovery. A CRDT can own draft convergence; committing a snapshot does not make all its intermediate history safe to disclose. p2panda's signed operations must be assessed for attribution and context linkage rather than treated as neutral containers (p2panda libraries).
#Variation — Adopt a library's shared-state semantics
A p2panda-based composition or DXOS/ECHO-style integrated workspace may remove duplicated merge and persistence work. It is admitted only if the chosen library's authorization, history, evidence, and export semantics fit the context. Installing a library does not make its defaults acceptable; equally, adopting its semantics should not create a second competing authoritative reducer. The shared-core synthesis and collaboration lane own this comparison.
Filtering an invalidated binary CRDT update is unsafe without accounting for later dependencies. Compare semantic corrections, dependency closure, and rebase/checkpoint admission before choosing rollback behavior. Matrix-style state events and contextual signed feeds remain narrower reference alternatives where federation or append-only history is actually required.
#Candidate responsibilities
| Component | Proposed responsibility | Acceptance gate |
|---|---|---|
| SQLite / rusqlite | Durable local accepted state and projections in the explicit-core variant | Crash recovery, migrations, duplicate/out-of-order inputs, and erasure of local indexes |
| p2panda-sync / p2panda-auth | Synchronization and, only if adopted, membership/authorization semantics | Compare actual conflict behavior, signature evidence, topic metadata, and export |
| Automerge / Yjs | Draft or shared-document convergence within an explicit authority contract | Actor/history leakage, invalidation dependencies, consent to published snapshots |
| DXOS/ECHO | Integrated shared-state countercandidate | One state owner, no unwanted identity proof, complete export and context separation |
| Object AEAD + recipient descriptors | Durable private representation independent of sessions or hosts | Context/revision binding, recipient removal, retention, and evidence profile |
#Falsification tests
- Promotion never exports session keys or admits an audience without the required grants and consent.
- An incoming object cannot downgrade the authentication profile established by its context.
- Recipient verification does not accidentally produce disallowed transferable personal proof, while a recipient cannot impersonate another writer to a different honest reader under the chosen model.
- Late readers distinguish newly authenticated old material, a currently endorsed checkpoint, and another participant's reported history.
- Duplicates, missing parents, reordering, and concurrent withdrawal do not make arrival order authoritative; unresolved transitions remain pending according to the declared policy.
- Moving a shared record between views does not silently change audience, ownership, or physical commitments.
- Stale replicas, repair, and recovery do not renew expired retention or restore withdrawn content outside the declared policy.
#Open questions and research links
#2 owns object/reference formats and migration; #3 owns authentication and consent evidence; #5 owns concurrent withdrawal, checkpoints, and late history; #11 owns meaningful-participant and artifact UX.
Continue to encryption, trust, access, storage, or profile tests. Earlier evidence remains in Wave 2; the September integration supplies the shared-workspace and history refinements. These are architecture hypotheses, not implemented protocol claims.