P2P Matrix protocol findings: separate the room, the keys and the network

#1. The architecture question has four independent axes

A device can connect directly to another device while still obeying a central authority. Conversely, a client can validate all application state locally while using a centrally hosted mailbox. These are different systems even when both are described as P2P.

For this evaluation, topology describes how bytes travel; authority describes who accepts state transitions; confidentiality describes who can inspect content and metadata; availability describes which operations remain possible during failure or partition. None of the four determines the other three.

The term local-first also needs an operation attached to it. Reading a cache, editing a document, admitting a device, publishing to a new audience, fetching a missing attachment and restoring a lost identity have different dependencies. A system that can send a local message while disconnected has not thereby solved all of them.

#The three Matrix-related architectures

The diagram compares responsibilities, not measured network performance. In particular, the Tachyon branch does not contain a hidden Neutrino or Dendrite instance.

#2. The supplied Pinecone diagram is historical, not the Tachyon wire format

The supplied image places Element above a local Dendrite homeserver. On phones, the client talks to the embedded server through a client-server interface, while the server participates in a peer overlay. In the browser variant, a service worker hosts a WebAssembly server and database. A conventional static server can participate as another peer. The image labels server-server traffic as CoAP, CBOR and DTLS over Pinecone with different underlying links.

That is an architectural experiment in moving a homeserver to the endpoint, not in removing the homeserver state machine. It retains a separation between a Matrix client and a Matrix room/federation engine, even when both execute on the same physical device.

The Are We P2P Yet history and its linked 2026 presentation describe later changes. The presentation's historical Dendrite drawing uses a different low-level stack, while its Neutrino drawing uses Iroh and CoAP. Consequently, the supplied labels must not be copied into a contemporary packet specification without a source revision. The website itself contains inconsistent dating between its displayed last-updated field and later body entries; this study treats it as a retrieved research/status page, not an immutable release manifest.

TalkCo consequence: the durable idea is a local implementation of authority with a replaceable network. Neither Pinecone, Dendrite, CoAP, CBOR, DTLS nor a service worker is logically required to preserve that idea. Each adds a separate implementation and lifecycle obligation.

#3. Neutrino moves a smaller Matrix engine to the endpoint

#3.1 Responsibility decomposition

The inspected Neutrino README describes an experimental Rust embedded homeserver. Its components separate whole-server control, HTTP routing, low-bandwidth mapping, room/event processing, storage traits, SQLite storage and platform bindings. The intended embedded Android path uses a separately built binding artifact.

This is relevant to TalkCo for three reasons. First, the room engine can be evaluated independently of a permanent hosted server. Second, the storage and transport seams are visible in code rather than merely diagrammed. Third, the experiment puts state resolution under intermittent connectivity, where hidden assumptions about a continuously available server become observable.

It is not evidence that conventional Matrix interoperability, application E2EE, arbitrary client features, background mobile reliability or an acceptable security profile are complete. The project's README explicitly warns against treating it as a production Internet server. Some of its individual statements also lag the implementation, so the warning and the source must be read together rather than replacing one with the other.

#3.2 Important correction: signatures are implemented, but not the base default

The README says event signatures and verification are absent. At inspected revision 90bc1b19ba2227a9afbcfcbdb90697a6892bcd1f, that is not a complete description of the code.

The event signing module implements EventSigner, KeyResolver, NodeIdKeyResolver, JSON/event signing and verification. EventSecurity::Signed invokes verification; the trusted-network alternative admits the event without that origin-signature verification. The control configuration selects signed mode when trusted_network is false, but its base default is true. The environment path similarly requires an explicit false/zero value to select signing.

The inspected startup source requires a key resolver for signed mode. The signed-federation test source includes successful two-node convergence and negative cases for an unknown signing key and a missing invitee co-signature. Those are stronger source observations than a function name alone. They are not tests executed in this evaluation, nor proof of the configuration shipped in an Android artifact.

Correct conclusion: Neutrino has a configurable signing/verification implementation at the inspected revision; its default trusted-network configuration and its broader experimental security status remain significant. "There is no signature code" and "it is now safe on hostile networks" are both unsupported summaries.

#3.3 The Iroh/BLE composition is a concrete adapter, not an anonymity layer

At inspected Neutrino-Iroh revision, the composition source injects an Iroh-backed DatagramLink through the embedded-server startup interface. It carries one CoAP datagram per unreliable QUIC datagram. The BLE path uses a custom transport with GATT and an L2CAP upgrade path, as described in the repository README.

The same source binds the endpoint to the node secret's Ed25519 public key. Embedded peer user IDs use the @n:{node_id} convention. The README describes BLE manufacturer advertisements containing node_id followed by display_name.

For TalkCo, this is a useful discovery of both modularity and correlation. The medium is replaceable without becoming the room engine. But persistent node identifiers and human-readable discovery names create an observer-visible association; proximity transport is not privacy by itself. Separating profile display names in the UI cannot remove an identifier transmitted in radio discovery.

A QUIC connection or relay path also does not promise persistent offline delivery. A separate component must retain ciphertext, enforce a finite custody policy and serve it after the original sender disappears. The new architecture should not call a transport relay a mailbox unless it actually implements that responsibility.

#3.4 A receipt can be technically valid and semantically wrong

Neutrino's control configuration contains an optional delivery-receipt feature. Its comments explicitly distinguish a remote server's successful federation transaction response from a person reading a message. The feature can expose the former using m.read, and the base configuration disables it.

The inspected Iroh/BLE startup function explicitly sets config.delivery_receipts = true. Therefore, inspecting only the generic default would miss a consequential composition-level change.

This does not establish exactly how the experimental Android UI labels the receipt. It establishes a boundary TalkCo must inspect. TalkCo's receipt policy requires separately typed states for transport acceptance, durable remote storage, application acceptance and a consented human-read signal. A server's 2xx response must not be projected as a person's attention or approval.

#3.5 State convergence is not identical client presentation

The same configuration exposes enable_soft_failure. Its comments say production-style client reads hide soft-failed events, whereas a convergence harness can display them to compare complete timelines. Soft-failure classification can be server-local and dependent on receipt order.

This creates an important test distinction. Equal accepted room state, equal retained event graphs, equal displayed timelines and equal user-visible acknowledgement state are different observations. An experiment that changes the visibility policy to obtain matching timelines must state that configuration. It cannot silently become evidence that ordinary user presentation is identical under every delivery order.

#3.6 Binding artifacts and licensing are part of the technical baseline

The Neutrino-Iroh README explains that its Android artifact records an exact upstream Neutrino commit, and that local Maven artifacts take precedence over the remote package source. A source checkout of Neutrino main, a checkout of the Iroh composition and an installed Android .aar can therefore represent different code. Source findings in this report are not combined into a claim about an unexamined binary.

The composition also separates vendored BLE crates with different AGPL version expressions from the main project's licensing arrangement. This is a dependency-qualification issue: record exact files, versions and terms before a reuse decision. Public availability, a research archive or permission from this repository's owner does not itself supply new rights to relicense upstream components.

#4. Tachyon is not an embedded homeserver

#4.1 Evidence provenance

The relevant deployment evidence is the existing Aurora research archive, captured on 2026-09-23. That archive contains public application assets, static WebAssembly analysis and isolated synthetic-client laboratories. This pass read the reports and selected source evidence descriptions; it did not rerun those laboratories or recapture the unavailable live site.

The distinction matters because "the public website currently does X," "the archived executable did X under a synthetic broker," and "a compiled function suggests X is intended" are different claims. The archive itself preserves those distinctions.

#4.2 Outer Matrix services, inner client-owned rooms

The wire chapter records these outer services:

A real Matrix deployment may use federation between homeservers to deliver these envelopes. The synthetic broker did not exercise that path. Nor did it establish a direct peer network, a server-independent account system or ordinary-server compatibility with every experimental key object.

#4.3 Device membership and user membership are not the same set

The archived DMLS join identity encodes user_id|device_id. The ordinary room membership representation can name a user, while cryptographic group leaves represent individual devices. Adding a second device therefore requires more than discovering that its user already appears in room membership.

The observed KeyPackage container uses org.matrix.experimental.dmls.v1.key_package in Matrix's one-time-key upload/claim interface. The captured package selected MLS suite 0x0003, corresponding to X25519, ChaCha20-Poly1305, SHA-256 and Ed25519. This is an observation about that package, not every linked algorithm, all negotiation paths or a post-quantum suite.

For TalkCo, a device admission rule must bind the new leaf to a context-appropriate credential and to current authority. An account service listing a new device is evidence to investigate, not permission to release every sphere's content keys. Device removal, replacement and account recovery need the same distinction.

#4.4 Admission is a protocol sequence, not a UI toggle

The archived flow has four logically separate steps. The creator authors an invitation event and sends an invitation envelope. The invitee sends an acceptance bound to that invitation and device identity. An authorized existing member obtains a KeyPackage and applies the cryptographic admission. A Welcome gives the new member cryptographic state together with encrypted room bootstrap state.

The consent object is valuable: an account name alone is not treated as sufficient evidence that an arbitrary device agreed to join. But a signed join acceptance is not TalkCo's consent to publish a private conversation, transfer an attachment to a new audience, or disclose a profile sphere. Those are different actions with different scope.

A two-member test may emit a Welcome to the sole new remote member without exercising the complete distribution pattern required when multiple existing members must accept a Commit. The small test must not be generalized into a claim that larger-group membership updates require no commit dissemination.

#5. The important innovation is the coupling of two graphs

The journal is an integration requirement in this diagram, not a claim that the archive proved a particular cross-store transaction implementation.

#5.1 Room event DAG

The room-DAG chapter distinguishes general causal parents, state parents, graph heads, missing ancestry and local trust/cache annotations. The implementation constructs and resolves room state on the client. Missing state dependencies can defer acceptance; later arrival can trigger settlement and re-evaluation.

In the archived two-peer run, two chat messages referenced the same prior join event and created two message-graph heads. The peers later produced matching canonical event exports. Local debug trust flags were not necessarily identical. This supports a small causal-message convergence result, not every room-version authorization rule or a byte-for-byte identical internal cache.

#5.2 Cryptographic epoch graph

The DMLS chapter identifies multiple cryptographic extremities, membership transformation, fork resolution and puncturable-function machinery. Cryptographic epochs describe which devices possess which evolving group secrets. They are not the same nodes as room messages.

Two simultaneous ordinary messages can branch the room DAG while using the same cryptographic epoch. Conversely, concurrent membership changes can create a cryptographic disagreement even when each peer has a simple local timeline. A message-order convergence test therefore does not establish secure reconciliation of concurrent additions, removals or re-additions.

#5.3 Decryption must not confer administrative authority

The implementation includes custom room authorization and state-resolution routines. In the archived laboratory, an ordinary member could exchange encrypted messages but could not perform the tested privileged rename; the creator could. That is a concrete illustration of the distinction between cryptographic membership and permission to change state.

The harder condition is that every accepted cryptographic membership transition must be justified by the appropriate accepted application state. A valid member signature on a Commit cannot by itself authorize that member to admit another device. Conversely, a room-state removal that is never reflected in the group keys does not exclude the removed device from future secrets.

Tachyon's justification and consent paths are therefore more important to TalkCo than whether its UI resembles Element. They address the seam at which an otherwise correct cryptographic library can be made to enforce the wrong audience.

#5.4 Experimental identifiers are not ordinary Matrix event compatibility

The archive independently reproduced several identifier derivations. Creation hashes canonicalized creation content into a room/event identity. Later state events used a custom SHA-256 input assembled from room, event type, state key, sender, canonical content, timestamp and parent lists. Application event identifiers were derived from ciphertext bytes. Group identity was domain-separated from the room identity.

The observed creation content's room_version: "12" is therefore not sufficient evidence of standard version-12 federation semantics. Similar names and familiar prefixes do not establish identical reference hashes, signature coverage, authorization or redaction behavior.

#6. The metadata claim must match the actual envelope

The archived invitation includes room identity and name, inviter, recipient membership event, ancestry, device-related identity, timestamp and signatures. The encrypted-message wrapper includes room and epoch identifiers and an encoded sender-device identity. Base64 encoding does not conceal these values. Delivery infrastructure also sees recipient fanout and traffic timing/size.

The encrypted Welcome state and encrypted application payloads do reduce what the delivery service must process semantically. The full ordinary room DAG is not sent to a normal homeserver room engine in the observed flow. That is a meaningful reduction in server responsibility, but it is not full metadata protection.

For TalkCo, the right measurement is an observer table: what a homeserver, current recipient, removed recipient, relay, nearby BLE observer, custodian, push provider and compromised endpoint can each learn. A blanket E2EE label loses precisely the distinctions the contextual-profile design needs.

#7. DMLS does not make ordinary MLS inherently centralized

The MLS architecture specification explicitly discusses both strongly consistent and eventually consistent delivery services. Ordinary MLS requires agreement on which Commit advances an epoch; that is a logical sequencing requirement, not a requirement for one irreplaceable physical server. A federated or peer-delivery application still needs a policy for conflicting commits.

The DMLS proposal investigates a different treatment of forks and retained state. The inspected datatracker entry still lists draft-03 as an expired Internet-Draft, not an adopted RFC. The binary's DMLS naming and linked machinery do not establish conformance to every detail of that draft.

TalkCo question: what exact concurrent-membership workload makes DMLS preferable to ordinary MLS with an explicit sequencing/retry rule, or to A0 recipient descriptors? Choosing a more complex epoch graph should purchase a measured availability or usability benefit, not merely a stronger decentralization label.

#8. Retention changes the security and recovery problem

The archived API returned 86,400 seconds for retention of message-ratchet material after an epoch ceases to be a current extremity. The report carefully distinguishes this from the lifetime of every private key and every secret in the implementation. It also reports a disabled experimental fork-readd Welcome path.

Retaining historical decryption material can preserve delivery for late messages; erasing it can narrow the consequences of later compromise. A client returning after relevant material has been retired may require recovery, selective retransmission or a fresh checkpoint rather than transparent decryption of everything it missed.

These are not arguments for one universal retention setting. A short-lived private conversation, a long-lived shared document and a deliberately retained publication have different persistence promises. TalkCo should place each in a declared evidence/retention profile and test actual database, backup, journal and crash behavior rather than infer erasure from an in-memory setting.

#9. What the current evidence supports

The evidence supports three research conclusions. Client-side authorization plus encrypted peer replication is a plausible and concrete architecture direction. The boundary between accepted room policy and admissible cryptographic membership is implemented enough to deserve deeper testing. Embedded homeserver transport seams provide a useful independent laboratory for local networks and intermittent connectivity.

It does not yet support a claim that the captured Tachyon client is direct-network P2P, that all metadata is hidden, that arbitrary DMLS membership forks converge safely, that a stock Matrix homeserver/client interoperates with its virtual rooms, that Neutrino's inspected source describes a particular deployed phone binary, or that either architecture satisfies TalkCo's deniability and custody requirements.

The composition analysis turns those limits into explicit adapter and adoption questions. The validation plan specifies observations that could change the recommendation rather than treating uncertainty as a permanent reason to reject the work.