Composing TalkCo with Matrix research without importing unintended authority

#1. Evaluate against the current project, not only the older stack diagram

TalkCo's older architecture chapter describes Session-lineage delivery, TACo and a Signal bridge-then-independent-fork strategy as stable working positions. The newer architecture profiles, research hub and architecture issue explicitly reopen how those choices fit together.

The newer provisional baseline is smaller: authenticated private objects, local persistence, contextual identity, separately chosen delivery and custody, recurring group epochs only where beneficial, and conditional release only for a named requirement. The smaller Rust-owned core and the integrated DXOS workspace candidate must be compared against the same fixtures. No universal signed private history or completed deniability construction is accepted.

This matters to the Matrix comparison. It would be misleading to ask only whether Matrix can replace Session's network or whether its UI can replace a Signal fork. The more consequential question is whether a client-owned Matrix room engine can remove a meaningful portion of TalkCo's authority, replication and group-security work without taking over decisions the product needs to keep distinct.

The research does not require preserving every old component. It requires explicitly reconciling any changed commitment in its owning documents rather than letting a convenient dependency quietly become the new design.

#2. Compatibility is a set of contracts, not one verdict

These are not independent checkboxes. Improving one can make another harder: more historical recovery material changes compromise exposure; wider peer discovery changes metadata; finer object audiences increase key-management cost; stronger public proofs change deniability.

#3. Four adoption paths, with different obligations

#3.1 Ordinary Matrix as an explicit interoperability surface

A TalkCo client can expose a conventional Matrix conversation mode or an explicitly consented export gateway. This purchases compatibility with the ordinary Matrix ecosystem, subject to the chosen client/server features. It does not make those conversations inherit every private TalkCo property.

The boundary should show which network owns the room, which metadata its infrastructure can see, which authentication/evidence profile applies, and whether a bridge is a plaintext-capable participant. Publication from a private context must not happen automatically because an integration was enabled once.

A bridge that decrypts a private object and republishes it into a conventional room is a new authorized disclosure endpoint. It is not an invisible transport change. A bridge that forwards opaque ciphertext avoids plaintext access but cannot make a stock client understand TalkCo's object semantics or cryptography. There is no adapter that both hides all custom meaning and makes an unchanged recipient fully interpret that meaning.

Research disposition: useful optional compatibility path, not the private-core default. It may be cheaper and more honest than attempting to preserve complete ordinary-Matrix interoperability while changing identity, event hashes, authorization and cryptographic evidence at once.

#3.2 Matrix as an opaque carrier

TalkCo could use Matrix to-device delivery for opaque application envelopes while keeping object acceptance and decryption above it. This resembles the responsibility split demonstrated by Tachyon, without requiring every TalkCo object to become a Tachyon virtual room.

The advantage is reuse of account access, device addressing, federation-backed delivery and client synchronization infrastructure. The costs are those services' metadata, retention, quota, device-list and compatibility contracts. The actual supported experimental key algorithms and event types must be tested with real server implementations; a permissive synthetic broker is not sufficient evidence.

The carrier's transaction identifier is not the object's identity. A successful request is not proof that the recipient durably accepted it. Account recovery is not authority recovery. Matrix device discovery is not permission to reveal all context credentials. Each of these separations needs an interface and a failure test.

Research disposition: a bounded transport experiment. It is acceptable only for an explicitly selected metadata profile, with a path to replace the carrier without rewriting object history.

#3.3 A Tachyon-style client-owned group engine

This is the most substantial Matrix-related architecture candidate. It may remove implementation work in recurring conversation groups: causal history, authorization checks, membership transitions, anti-entropy and integration with an encrypted group state machine.

The comparison should begin with one stable group and one shared-object checkpoint, not the whole application. The engine must demonstrate safe concurrent membership, device lifecycle, admission consent, crash recovery, bounded ancestry work and the required authentication profile. A room model is accepted where it fits; it is not imposed on every file or channel merely because it is already implemented.

A reuse decision also needs exact source, licensing, build reproducibility and a sustainable maintenance relationship. The archived browser binary is valuable evidence but is not a maintainable source dependency by itself.

Research disposition: add a bounded group-engine countercandidate to the same fixture used for the smaller core and DXOS. Require a demonstrated reduction in total maintained work after adapters, not only a working chat demonstration.

#3.4 Neutrino as an embedded server or research laboratory

Neutrino can test intermittent federation, room-state resolution, mobile persistence and heterogeneous links. It may also be a local compatibility facade for clients expecting a Matrix client-server API.

It should not automatically be placed underneath Tachyon. Doing so could retain two room engines, two persistence models and two recovery paths while the inner Tachyon engine still decides the application's meaningful state. A second engine is justified only when it supplies a specific compatibility, routing or storage responsibility that cannot be supplied more narrowly.

The inspected Neutrino/Iroh composition is especially useful as a reference for a transport injection seam. Its persistent identifiers, signing mode, delivery receipts and platform artifact configuration must be qualified independently. A local server must also authenticate its callers; loopback alone does not establish that every process or embedded web view is entitled to private state.

Research disposition: transport/state-resolution and platform reference, with any adoption gated by a measured responsibility. It is not currently evidence of a complete TalkCo private backend.

#4. One owner for each state machine

The system needs several kinds of state, but not several competing authorities for the same kind. Modularity is valuable when it gives a replaceable responsibility; it is harmful when it creates duplicate logs and ambiguous recovery.

This is a proposed ownership map, not a requirement to write every box from scratch. A reviewed library can own several boxes if its semantics are explicitly accepted and recovery remains coherent.

#4.1 A receive path must validate more than encryption

A research implementation should make the following sequence auditable: bound parsing and allocation; identify the expected context/profile; reject unsupported or downgraded versions; deduplicate the application operation; authenticate/decrypt using the expected credential and epoch policy; obtain required dependencies within resource limits; check application authorization and disclosure scope; atomically record accepted state and crypto consequences; enqueue any required durable effects; update disposable views.

The sequence is not a prescription to decrypt before every possible cheap check. Cleartext routing can be checked first, and different message families need different dependency handling. The invariant is that cryptographic state, room/object authority and acknowledged durable success cannot diverge because one subsystem committed while another failed.

An incoming packet must not choose a weaker authentication profile than the receiver already expects for that context. A valid object hash is not proof of origin. A valid origin proof is not an edit grant. An edit grant is not permission to expand the audience. An audience grant is not a promise of durable custody.

#4.2 At least five graphs can coexist

The room/message DAG records causality. The authorization graph records which changes justify which powers. The cryptographic epoch graph records secret and device membership evolution. A document CRDT records content operations. The custody/transport history records copies, retries, leases and acknowledgements.

These may share identifiers or storage, but their correctness criteria differ. A merged document can contain an unauthorized edit. A validly encrypted message can embody an unauthorized audience change. A well-repaired ciphertext can be undecryptable because the required descriptor was lost. A converged room can still show different local safety filters. Tests must observe all relevant projections, not only equal replica bytes.

#5. Contextual identity is not solved by replacing domains with keys

#5.1 Separate five identities

TalkCo should distinguish a person as known locally, a profile-sphere credential, a device credential, a carrier route and a custody/accounting identity. These may be linked where explicitly needed, but a single public key reused in all five positions creates a public join key across the system.

The archived Tachyon identity includes a Matrix user and device. Neutrino/Iroh uses a persistent node key for endpoint and federation naming, and its source documents the same secret's relationship to origin signing. Those are understandable implementation choices. They are not the contextual-privacy construction TalkCo describes.

A per-room or per-context pseudonym helps only if surrounding proofs, device lists, push endpoints, transport connections, directory lookups and storage requests do not trivially reunite it with the same root. Creating many pseudonymous Matrix accounts on one service may conceal associations from ordinary recipients while leaving them obvious to that service. Privacy claims must name the observer.

#5.2 A practical privacy profile needs an explicit budget

For each traffic class, declare which observations are acceptable: destination identity, source IP, room/topic handle, device multiplicity, approximate time, payload size, contact frequency, proximity, public-key continuity and storage access pattern. A direct-link profile may intentionally reveal network location to consenting peers; a private-route profile may hide some links at additional latency and resource cost.

No carrier should silently fall back from the latter to the former. Transport negotiation itself must not disclose the private context to an unauthenticated discovery service. BLE advertisements require special care because a nearby passive observer need not be a conversation participant.

Public-key account proposals in Matrix may improve mobility and reduce domain dependence. That is useful, but portability and unlinkability are different properties. A stable self-certifying identifier can make a person more portable and more correlatable at the same time.

#5.3 Recovery is a new authority event, not a restore command

Restoring a database may recover history, old keys, pending operations and revoked device credentials. It does not prove that all those credentials are still authorized. A recovery path must separately answer what historical material may be read, how current device membership is re-established, whether peers must consent, which old keys are retired, and whether a copied backup can impersonate an active device.

Self-certifying node identities make key replacement especially visible: replacing the key may replace the address and origin identity. Conversely, retaining the key for seamless continuity preserves the consequences of its compromise. A recovery system must choose the expected evidence and continuity properties rather than infer them from a hash-based name.

#6. The private-authentication problem remains open after choosing MLS

TalkCo's newer research explicitly rejects the assumption that every private statement should become a transferable public-key attestation. MLS and DMLS can supply strong cryptographic membership/authentication mechanisms, but that does not by itself satisfy this evidence requirement.

The relevant object is an evidence graph: private message authentication, invitation acceptance, device certification, a signed group checkpoint, an object descriptor, an upload receipt, a consent record and a recovery proof may together bind a person's identity to private content. Encrypting the graph in storage does not necessarily prevent a recipient who has the necessary material from presenting it elsewhere.

Three profiles should remain distinct. A private conversational profile needs a precisely stated recipient-simulation/non-transferability target and reviewed construction. A durable shared-workspace profile may deliberately retain certain authorship evidence while restricting its identity scope. A public publication profile may intentionally create transferable attestations. Neither the UI label "private" nor use of a group cipher selects among them.

The existing candidates—ratchets, selected HPKE authentication modes, contextual credentials and designated-verifier approaches—must be evaluated as complete compositions. No generic claim that HPKE, a shared group key, a signed DAG or a particular library automatically supplies deniability is accepted here. A shared MAC also does not identify individual writers against other holders of the same key.

The adoption consequence is substantial. Replacing a library's authentication layer can change its threat model enough that the result is a new cryptographic protocol, not a harmless adapter. Exact scope, independent review and source-level evidence are required before counting the original library's guarantees as inherited.

#7. Offline authority has an information limit

Consider a group with Alice, Bob and Carol. Alice removes Carol while Bob is partitioned. Before receiving that removal, Bob encrypts new material to the audience he still believes current. Carol obtains it. The replicas later reconcile to a state in which Carol is removed.

No later deterministic ordering can make Carol forget material already obtained. Bob could not distinguish this execution from one in which Alice had not removed Carol, unless the operation required a fresh external fact that the partition prevented him from obtaining.

This is a model of the information boundary, not an exploit executed against Tachyon or Neutrino.

#7.1 Separate editing availability from disclosure authority

TalkCo can permit an offline draft or record edit while delaying a sensitive disclosure until the required freshness condition is satisfied. Other contexts can explicitly accept causally observed revocation: once a device learns a removal, it must stop using superseded audience grants, but previously disconnected senders may have acted under earlier knowledge.

A lease or checkpoint can limit staleness, but it introduces a clock, issuer, witness, quorum or connectivity assumption. A threshold release service can change who must cooperate; it cannot magically know an unseen revocation. The failure policy must say whether release waits, expires, becomes provisional or is permitted under a bounded stale view.

#7.2 Define conflicts by operation

Concurrent admission/removal, ownership transfer, role changes, audience widening, content edits and personal blocks do not all need the same rule. A remove-wins data type may give a deterministic membership set, but the associated key transition and already performed disclosures need additional semantics.

An object edit can often remain as a rejected or provisional operation without granting its author new rights. A publication that expands an audience should require the appropriate consent and context binding before any new recipient key is released. A local block should not need a consensus transaction merely to stop displaying or notifying about someone.

The protocol should preserve useful action without pretending every action is coordination-free. This is where the existing CRDT/authority research and the Matrix state-DAG work should meet.

#7.3 Finality needs a subject and a failure model

A final room checkpoint, a durable ciphertext copy and a completed consent process are not one kind of finality. A checkpoint can stabilize an accepted history for a named epoch without proving that no isolated device will ever return with a conflicting authorized event.

Before adopting finality machinery, define who may finalize, which evidence is required, how unavailable participants are treated, what later contradictory history means and how old cryptographic state is retired. A universal majority rule may be inappropriate for a group whose majority is normally offline. A permanent privileged coordinator may conflict with the intended authority model. These are product/protocol choices, not implementation details to inherit accidentally.

#8. Rooms are useful containers, but not universal objects

#8.1 Choose the smallest authorization scope that preserves meaning

A recurring group conversation can reasonably share a membership and epoch. A channel with stable readership can benefit from repeated cheap encryption to the same audience. A sensitive attachment or a reply with a narrower audience may need an object-specific descriptor instead.

Putting all these into one room grants every room member the same group decryption boundary unless additional encryption is applied. Splitting every tiny object into its own room avoids some overgranting but creates room, membership, key, sync and recovery overhead. The right comparison is measured total cost for the actual audience distribution, not a categorical preference for rooms or objects.

#8.2 Sharing a reference does not necessarily share the object

A local view can move a reference without changing the underlying object's audience. A user can deliberately publish a new artifact derived from a private conversation, with new consent, context and encryption. A custody host can receive ciphertext without a content key. An editor can receive a write grant without becoming a moderator of the surrounding community.

These distinctions should be explicit in the schema and command boundary. A bridge or CRDT that treats all link movement as a globally visible graph edit can violate them even when every byte is encrypted on the network.

#8.3 History admission is a separate grant

A new device or late group member may need selected prior material rather than every historical key. A current checkpoint endorsement can establish what present participants now accept without recreating original historical authentication. Re-encrypting selected content can grant access but cannot change what earlier recipients learned or what original proof exists.

For a shared grid, stable row/object identity and formula dependencies must survive a checkpoint. For a private conversation, retaining all history merely to simplify late-device recovery may conflict with the intended retention profile. Neither a group Welcome nor a generic database snapshot decides these policies.

#9. Hosting must remain custody, not membership

A non-reading host needs an opaque identifier, bytes to retain, a finite storage/retrieval grant and a repair/accounting contract. It does not need the group's application decryption keys or the right to admit devices.

An MLS group member is therefore not the default representation of a storage provider. A provider can carry encrypted group traffic without joining the cryptographic group. A homeserver's media API may supply useful byte transfer, but TalkCo still needs to qualify retention, redundant custody, integrity, private access, expiry and what happens when the account or server disappears.

Application encryption should precede a content-addressed custody representation where equality or confirmation leakage would be unacceptable. A content hash proves byte identity against a trusted reference; it does not prove authorship, authorization, current availability or who is entitled to read. Reusing deterministic object identifiers across contexts can undermine otherwise separate credentials.

For deletion, distinguish local reference removal, cooperative provider expiry, key retirement, repair cancellation and copies already held by readers. No remote tombstone proves that every plaintext or historical backup vanished. A repair job must not resurrect material whose retention authority has expired just because another replica still has the bytes.

#10. Other technologies fit at named seams, not as a tower of protocols

This section interprets candidates already in the master research table. Except for the Matrix sources specifically refreshed in this study, their implementation-status claims retain the dates and limitations of the existing research. This is not a new comprehensive freshness or license audit.

#Session, Lokinet, Iroh and libp2p

Session-lineage store-and-forward and onion-request ideas address different requirements from a client-owned room engine. They may carry opaque TalkCo control traffic without deciding membership or object semantics. Lokinet's richer connection-oriented role likewise belongs below the application contract. Neither removes correlation caused by reused application identifiers.

Iroh and libp2p are candidates for connectivity, not substitutes for the private-object protocol or durable custody. A direct connection can be valuable for local operation and large transfers, but its observer profile must be acceptable. A relay that forwards current traffic must not be counted as a durable offline copy. Do not route the same effect independently through multiple libraries unless the core owns duplication and acknowledgement semantics.

#p2panda and Willow

p2panda's networking, synchronization and authority components may remove more work than a transport alone. That makes it a substantive substrate comparison, not a mandatory additional layer under Matrix. The accepted author/topic identifiers, role accumulation and evidence behavior must be evaluated before combining its history with a Matrix history.

Willow's namespace, capability, selective-sync and asynchronous drop ideas are particularly relevant to object-specific disclosure and offline transfer. A Matrix carrier could transport an opaque drop without understanding it. The private-interest and namespace contract must still be evaluated against TalkCo's context model; transferable capabilities and stable namespace IDs do not disappear merely because the transport is private. Avoid letting Willow and Matrix independently become the authoritative log of the same object.

#Automerge, Yjs/Yrs, Loro, Keyhive and related authority work

A content CRDT can own document or grid convergence while a selected group protocol protects its updates. Authorization is not supplied merely by placing CRDT bytes inside a group. Removed writers, dependency closure, stale grants, late-reader history and checkpoint signatures remain explicit tests.

Keyhive, p2panda-auth and the capability/CRDT references in prior research are useful alternatives for the authority seam. They should be compared against the same concurrent-admission/removal scenarios as Tachyon's room-policy/epoch coupling. Stacking all of them produces more authority systems to reconcile, not stronger security by addition.

#DXOS, NextGraph, Fireproof, OrbitDB and Jazz generations

DXOS remains the existing integrated-workspace countercandidate. Its value should be measured as a possible replacement for a substantial set of modules. Adding a full Matrix/DMLS engine beneath it is only justified if the combined identity, log, recovery and custody models remain simpler after integration.

NextGraph is similarly an integrated architecture comparison, not simply another storage driver. Fireproof and OrbitDB remain bounded alternatives with specific metadata/key and access-controller tests. The repository already distinguishes Classic Jazz from the server-authoritative v2 generation; the privacy description of one must not be attributed to the other.

For every integrated framework, ask which accepted state machine it owns, how it exports a context without a global identity leak, and whether plugins or app credentials gain broader access than the product requires. A convenient workspace demo is not evidence of the complete private-core contract.

#ERIS, Kapla, Tahoe-LAFS/ZKAP and a small Rust custody service

These address immutable representation, storage and private accounting, not room membership. They can be paired with a Matrix-derived or non-Matrix application layer. The shared comparison must use the same application ciphertext, lease assumptions, fault schedule and repair budget.

ERIS is a format experiment, not a custody network by itself. Kapla is a node comparison, not proof of the desired lease semantics. Tahoe/ZKAP and a smaller Rust service can each change the amount of operational code TalkCo maintains. The source of key authority must remain outside a host that is intended not to read.

#MLS/DMLS, TACo, PRE and scoped capabilities

MLS or DMLS may be justified for recurring groups. Conditional release mechanisms may be justified when a named condition or divided authority cannot be supplied adequately by ordinary recipient-held keys and grants. They do not need to run on every feed read.

TACo/PRE can introduce liveness, committee, metadata and recovery dependencies; they should be compared against the actual release condition rather than retained or rejected solely because they appeared in an earlier diagram. A threshold signature, threshold decryption and consensus decision are different mechanisms. None should be inferred from the shared word "threshold."

UCAN, Biscuit or a minimal grant format may express a finite service action, but a signed token can create transferable evidence. A custody allowance, publication consent and device admission should not be collapsed into one universal token with ambient authority.

#Rust, SQLite, Effect, TanStack DB and client shells

The Rust-owned core can persist accepted state, cryptographic transitions and an outbox. SQLite encryption, platform keystores, backups and crash testing determine actual local protection. A Tauri/React, native or browser shell is a platform choice with its own trusted computing base.

Effect may own cancellable UI tasks while TanStack DB projects a bounded snapshot and deltas. Neither should independently redefine durable success or retry an already core-owned side effect. A browser's same-origin scripts, service worker updates and storage lifecycle require a different threat model from an installed native binary. Reusing Signal-like interaction patterns or Element components does not grant access to either network or preserve all of its original crypto properties after backend replacement.

#11. Changes belong at the layer that can enforce them

Some improvements can be made entirely in TalkCo's client, especially notification policy and presentation. Others cannot: a client cannot make an already visible server envelope private, revoke already distributed keys or force an unmodified peer to enforce an unknown authorization rule. A homeserver extension can improve queueing without solving private evidence or object consent. A new room version can define validation but does not by itself supply network anonymity.

For Matrix upstream, the highest-value contributions would be precise client-authority profiles, reproducible source and interoperability vectors, safe membership/epoch reconciliation, explicit identity and recovery semantics, transport-neutral retention/acknowledgement contracts and bounded resource behavior. TalkCo-specific UI preferences need not become global Matrix requirements.

#12. Questions that should be asked before an adoption decision

#What exactly must remain possible when every infrastructure provider is unavailable?

List operations, not slogans: local read, draft, shared edit, first contact, new-device admission, sensitive publication, history recovery and attachment repair. Test them with only the participants actually reachable. A system can preserve useful local work while intentionally refusing fresh disclosure it cannot authorize.

#Which observer is each context protected from?

An ordinary recipient, a homeserver, a storage provider, a nearby radio observer and a global network observer have different views. Define the claim before choosing routes. Context privacy against one does not imply context privacy against the others.

#What would a recipient be able to prove after exporting every adjacent artifact?

Include signed device introductions, invitation consent, history checkpoints, receipts, key backups and deliberately published derivatives. The answer may differ for conversation, shared record and public publication. The private profile needs a complete construction and adversary model, not a library checkbox.

#Does a protocol-valid action carry the social permission the application intends?

A room power threshold can authorize a technical operation without legitimizing every community consequence. Conversely, ordinary initiative should not require a formal administrative transition when the object model can permit a narrow action. Technical custody, content editing, norm facilitation and community-wide authority should not share one implicit superuser.

#Who pays for old history and what remains when they stop?

Bound queues, leases, key history, ancestry caches, inactive groups and repair work. A home server, relay or friend hosting ciphertext has finite resources. Introduce private allowances without turning every read into a globally linkable identity event.

#Can a malicious reader cause disproportionate work without breaking cryptography?

Validly authenticated forks, ancestry requests, repeated Welcomes, stale epoch probes and huge dependency chains can consume storage and CPU. The resource budget is part of the protocol, including how failure remains interoperable.

#Can the client safely replace its own identity or recover from rollback?

A local backup can resurrect a revoked credential or a consumed one-time key. A restored outbox can resend a once-valid disclosure. Test rollback, two copies of one device state, key rotation, route changes and conflict between historical evidence and current authority.

#Which compatibility is actually required?

Separate Matrix account compatibility, transport compatibility, room-event compatibility, encryption compatibility, client rendering and full application semantics. Tachyon's use of Matrix APIs establishes only some of these. Decide where a deliberate new dialect is acceptable and how it will be labeled and migrated.

#Can an adapter be removed without exporting private history or rekeying everything?

Define the export artifact, credential continuity, pending-delivery handling and retained custody capabilities. A carrier-independent object ID helps; a carrier-specific root credential or encrypted state format without source can prevent a clean exit.

#Are post-quantum and compromise-recovery goals actually specified?

The captured DMLS suite is classical. A post-quantum transport would not retroactively change its group key establishment or all retained backups. Define the required protection period, upgrade mechanism, downgrade behavior and multi-device transition before selecting suites.

#Does the actual binary match the repository being evaluated?

Require source commit, dependency lockfile, build flags, artifact hash and runtime configuration. The Neutrino/Iroh composition's receipt override and artifact revision reporting demonstrate why generic README/default-branch reasoning is not enough.

#What result would make us stop adapting Matrix?

A bounded experiment should have an exit criterion. If preserving contexts, private evidence, object audiences and recovery requires replacing most of the room engine and crypto integration, retain Matrix as a carrier/interoperability reference and choose a smaller native object core. If a client-owned Matrix component passes those boundaries and removes substantial maintenance work, adopt that responsibility rather than recreating it for ideological purity.

#13. Provisional conclusion

Tachyon is relevant because it relocates room authority, not because it proves every desired P2P property. Neutrino is relevant because it exposes embedded room/transport boundaries, not because an embedded server is automatically a complete local-first private platform.

The strongest composition keeps TalkCo's contexts, object meaning, disclosure and evidence requirements explicit; uses a reviewed implementation for each accepted authority/merge responsibility; selects group epochs only for recurring audiences that benefit; and treats carriers and ciphertext custody as replaceable, measured services. Ordinary Matrix interoperability remains deliberate and labeled.

That architecture may ultimately adopt substantial Matrix-derived code. It may instead borrow the dual-DAG/authorization lessons while using A0 objects and other delivery mechanisms. The next decision is a same-fixture comparison with source and failure evidence, not a declaration that one ecosystem must own the whole stack.