#Portable data need not be public evidence
A Social Filesystem motivates open records independent of clients. AT Protocol repositories add signed roots and transferable inclusion evidence. The former does not require the latter. TalkCo's private/shared filesystem must not become a public repository of every sphere or action.
Posts, tasks, documents and shared databases can use stable logical IDs, immutable representations and checkpoints. Paths, grids and feeds are views. A live database is not synchronized merely by copying its database file. Kaupapa is ordinary contextual content, not an authorization program.
#Contact-specific keys and deniability are distinct
A pairwise signing public key can conceal its personal association while still producing verifiable signatures under that key. A transferable introduction, certificate, recovery record or published reuse can restore the person-to-key association. A contextual key with a deniable personal binding is a separate candidate from a non-transferable message authenticator.
Requiring the recipient's private key is insufficient: in EncryptToBob(post, AliceSignature(post)), Bob can disclose the decrypted signature without disclosing that key. A narrower content key may also be disclosed. The desired property comes from recipient simulation or a carefully analyzed deniable identity binding, not from making disclosure costly.
The target must distinguish offline transcript transfer from an online cooperating observer, endpoint compromise, testimony and traffic analysis. X3DH and PQXDH explicitly qualify their deniability models. No general promise about all external evidence follows from a protocol name.
#Separate bytes from source authentication
The proposed private-object path is application AEAD ciphertext → ERIS or another immutable representation → independent hosts. Each recipient separately receives a protected descriptor binding the exact representation, logical revision, context, audience, freshness/causality information, recipient key version and authentication profile.
One large ciphertext can serve several readers without a universal author signature. The descriptor authenticates what a contact intended to share; block hashes check retrieved bytes; the content key permits decryption. A read key is not automatically an author credential or edit grant.
ERIS describes intermediary-peer deniability, not this personal-authorship property. Its suggestion to sign read capabilities is not a private-profile default. The proposed application-encryption-before-ERIS boundary remains intact.
#Mechanisms to test
Established ratcheted relationships are the leading descriptor-delivery experiment. Do not add a personal signature over private payload hashes that defeats the session's evidence boundary. Equally, do not remove necessary prekey authentication indiscriminately: a generic prekey certificate does not automatically bind a particular message.
HPKE Auth with DHKEM is a bounded alternative. The RFC relates recipient-key-compromise impersonation to repudiability; static recipient keys lack recipient forward secrecy, and replay/application binding is external. Base mode alone does not authenticate senders. These properties must not be assumed for arbitrary draft hybrid suites or the entire multi-recipient composition.
deevee exposes designated-verifier signing, verification and simulation, but is experimental reference code rather than an approved security boundary. Multi-recipient collusion, key lifecycle and public linking require analysis independent of a single-verifier example.
Authentication mode is accepted context state. An attacker cannot select a weaker mode by omitting a signature or editing an object field.
#Co-owned history and late readers
A shared group MAC or decryption key does not distinguish writers against insiders. For small groups, compare per-recipient authenticated change batches. For larger shared objects, compare contextual signatures with deniable personal bindings. RFC 9750 discusses the latter avenue while declining a general MLS deniability claim. Ordinary MLS messages contain signatures; encrypting them does not itself make them non-transferable.
A late reader can receive retained material reauthenticated by the author, a checkpoint endorsed by current participants, or another participant's reported historical view. These establish different facts. The app must label the evidence appropriately and separately refresh current membership. An old backup restores data, not revoked authority.
Content hashes identify versions, not freshness or social adoption. Public witnesses and signed roots must be evaluated for their effect on private attribution before being introduced to resolve divergent histories. CRDT operations cannot be filtered after revocation without considering dependent changes; authorization semantics belong in the collaboration lane.
#Custody and deduplication boundaries
Contribution, reading, control of future access, ciphertext custody and repair are different relations. Moving an alias need not change an audience; a real audience expansion requires the applicable grants and consent. A host's ability to identify bytes does not establish personal authorship or ownership.
Replicate one encrypted representation within its intentional sharing domain. Unrevealed contexts normally require fresh representations. A recipient may privately know that two authorized views correspond to the same item without publishing a global equivalence marker. Releasing one lease does not delete another holder's valid copy; stale repair must not renew expired retention. Packing blocks physically must not make unrelated content keys inseparable.
#Audit the complete evidence graph
Review signed feed roots, inclusion proofs, upload requests, quota invocations, custody receipts, consent records, acknowledgments, introductions and recovery manifests. A signature on a hash can bind content as effectively as signing the text. The meaning matters: a host attesting custody is not necessarily attesting composition, while a personally linked approval of exact bytes can create the evidence we wanted to avoid.
A local record can say how a file was authenticated without becoming a public credential. A moderation outcome establishes the reviewer's action, not automatically the original author's uniquely provable speech. Private blocks remain unaudited and sensitive reports must not enter general community memory.
#Reporting, attestation and retention
Deniability does not prevent reporting experiences or making protective judgments. It changes what a recipient transcript cryptographically proves. Hecate studies designated moderation/message franking with additional protocol/trust assumptions; it is not a hidden default verifier.
Ordinary consented publication can create a newly approved artifact and intentional attestation now. It need not prove the timestamp or authorship of every private source sentence. NOTRY studies the stronger retroactive-avowal question separately.
Erasing old session keys while retaining an encrypted archive gives that archive its own compromise exposure. Do not keep every old authentication secret merely to recreate an audit trail or claim erasure while recoverable content keys survive in backups. Declared retention applies to keys, descriptors, indexes and previews as well as payloads.
#Decision gates
Issue #3 owns the exact construction. It must test outsider forgery, recipient simulation without impersonation to another honest recipient, exported evidence, file tampering, author-offline delivery, late joins, context separation, recovery and deliberate attestation. #2, #4, #5 and #12 own the adjoining semantics.
DXOS, OrbitDB, Classic Jazz, p2panda, Hypercore and other signed-history candidates need a complete key-to-content evidence review. A deniable identity-binding profile may work; encryption of signed history alone is not enough. No such implementation was built or tested in the source review.
#Evidence and open questions
Primary links were collected in the supplied September 19 analysis; this condensation does not claim a fresh cryptographic audit. The encryption page owns the concise mechanism comparison. The issue map owns routing.
The unresolved questions are the exact observer/key-disclosure model, acceptable group fanout, late-history requirements, which control records need transferable evidence, and recovery/retention without resurrecting authority or unnecessary private commitments.