Matrix P2P evidence, computational models and falsification plan

#1. Evidence classes and boundaries

The live Aurora site could not be freshly retrieved in this session. The app-specific findings therefore refer to the 2026-09-23 archive, not an assumed unchanged live deployment. The archive's limitations are retained: exact custom Rust source revisions/source maps were not recovered; real credentials, real room traffic and federation were not used.

#2. Primary source ledger

Retrieval/inspection date for this study: 2026-09-24. Mutable web pages retain that observation date. Immutable repository links identify the inspected revision; they do not identify an installed mobile artifact unless its build provenance separately matches.

The supplied image is a user-provided historical diagram, not newly discovered source code. It was inspected as an image; no OCR-derived claims are required. No upstream source or artifact is relicensed by this study. Existing third-party provenance remains in the Tachyon archive rather than being duplicated wholesale into TalkCo.

#Source discrepancy register

#3. Executed analytical model

The companion Python model uses only the standard library and performs no network calls. The stored results are machine-readable. It was executed locally in this research session and checked against its deterministic output.

python3 docs/research/2026-09-24/matrix-p2p-model.py \
  --check docs/research/2026-09-24/matrix-p2p-model-results.json

The success message explicitly says no implementation was tested. Re-running the script establishes reproducibility of these calculations, not a pass for the future integration tests.

#3.1 Fanout is counted in devices, not people

Let U be users, d devices per user, D = U*d total devices, M application messages per group per day, and E assumed bytes per delivered envelope. Under unicast delivery to every device except the originating device:

recipient deliveries per application message = D - 1
recipient deliveries per group day = M * (D - 1)
aggregate delivered bytes per group day = M * (D - 1) * E

This includes another device belonging to the sender's user. A server can perform fanout after one sender upload, so aggregate recipient bytes must not be described as the author's uplink cost. A different distribution tree, batching policy or relay design changes where work occurs, not the need for intended recipients to obtain relevant content.

The illustrative parameters are two devices per person, 500 total application messages per group per day and 1,280 bytes per delivered envelope. They are deliberately stated assumptions, not measured Tachyon message sizes or a forecast of TalkCo use.

The model excludes retry/control traffic, additional framing, compression, attachments, custody replicas and repair. Those must be measured. It also records balanced binary-tree height only as an asymptotic comparator; a logarithmic key-tree path is not evidence of logarithmic total network distribution.

If instead every device emits r messages in the same interval, then M = r*D and aggregate recipient deliveries become r*D*(D-1). That quadratic group-wide workload is a workload assumption, not proof that the implementation performs quadratic work per one message.

#3.2 The revocation schedule model

The abstract model has three events: removal accepted at Alice, Bob learning that removal, and Bob attempting a release. It imposes only the causal requirement that Alice's removal precedes Bob learning it. Bob releases if his current local view still contains Carol.

All three schedules are enumerated. They are not equally likely outcomes and their counts are not probabilities. The model establishes the simple information boundary: preventing the middle schedule requires a different release precondition or a weaker global revocation promise, not merely a later deterministic merge.

The model does not implement MLS, DMLS, Matrix state resolution, cryptographic keys or a hostile client. It must not be cited as a demonstrated Tachyon vulnerability. Its role is to prevent an impossible acceptance criterion from entering TalkCo's integration plan.

#3.3 Cost dimensions not measured here

A future benchmark must separate initial download size, compiled/runtime memory, per-device group state, event ancestry storage, retained epoch secrets, key-package churn, state resolution, application fanout, attachment transfer, recovery and mobile energy use. The archive's WebAssembly file size is an artifact size, not browser peak memory or actual compressed transfer size.

For a sequential epoch history, a simple planning model of retired epochs scales with membership-change rate times retention window, subject to implementation retirement rules. Forks add branch-dependent state; convergence, puncturing, persistence and cleanup may change the result. No exact DMLS memory bound is inferred here.

Similarly, an event graph's size alone does not establish the cost of repeated state resolution. Missing dependency requests, adversarial branches, cache behavior and settlement scheduling can dominate. Benchmark accepted work and rejected work independently, including how a peer applies backpressure.

#4. Shared implementation fixture

Use the fixture already required by TalkCo's profiles rather than a chat-only demonstration. Alice, Bob and Carol have distinct authenticated devices; at least one user also has a second device. Two profile contexts must remain unrevealed to one another. Include a private conversation, a consented publication, a shared record/grid, a document checkpoint, a private attachment, a late reader, a non-reading custodian and a replaceable relay.

Run the same logical workload against the smaller A0 core, a bounded client-owned Matrix/DMLS group path and the existing integrated-workspace countercandidate. Do not force every candidate to use the same internal representation. Compare the same externally meaningful acceptance, disclosure, evidence, custody and failure outcomes.

Record exact source/dependency revisions, build flags, platform, configuration, deterministic seeds, delivery schedule, input objects, expected results, actual traces and limitations. Distinguish imported source tests from tests actually run. Preserve failures and unsupported operations rather than turning successful process exit into a universal pass.

#Observation vector after each operation

accepted object/state revision
accepted membership and per-device authority
cryptographic epoch/extremities and decryptable audience
locally durable state and outstanding outbox operations
displayable content and local attention/filtering state
retained custody copies, leases and repair obligations
exportable authentication/consent evidence
observer-visible identifiers, routes, timing and sizes

An implementation passes only the dimensions relevant to its declared profile. A matching debug JSON export is neither necessary nor sufficient when local trust annotations or legitimate local filters differ.

#5. Proposed protocol and adversarial tests

Status of every test below: NOT RUN in this study. These are assignment-ready research gates, not asserted results. Existing archived Tachyon tests are separately identified in section 1 and are narrower than these cases.

#Resource and safety limits for the laboratory

Use synthetic identities, consented test devices and controlled rooms only. Do not send malformed traffic to unrelated production rooms or enumerate real accounts. Bound event count, object size, epoch/fork count, concurrent requests, wall-clock runtime and captured trace retention. Raw captures can contain keys or plaintext even when the external protocol is encrypted; store them with appropriate access and avoid publishing real participants' data.

For source execution, pin repositories and dependencies, record licenses, and isolate third-party test execution from write credentials. Documentation CI should not be treated as the place to run arbitrary upstream code with repository-write authority.

#6. Decision gates and stop conditions

#Gate A: precise source and compatibility baseline

Obtain exact custom Tachyon source/lockfile/build flags, the archived artifact hash, and the intended room/DMLS profile. Reproduce its basic synthetic behavior and then establish real-server behavior separately. Do not spend an integration budget on a binary-only dependency whose protocol may be changing without a migration contract.

#Gate B: context and evidence feasibility

Before broad UI integration, demonstrate two unrevealed contexts and the selected private evidence profile through the full invitation/device/recovery path. An adapter that requires replacing most authentication machinery must be estimated as new protocol work. Failure here can narrow Matrix to explicit interoperability or opaque transport rather than disqualifying all Matrix research.

#Gate C: authority and partition correctness

Run concurrent membership and object-authority fixtures with delayed/duplicate/maliciously scheduled traffic. Require agreement on authorized effects, not just total event ordering. Document the revocation freshness policy and the set of operations intentionally unavailable during partitions.

#Gate D: platform and custody operation

Measure crash recovery, background constraints, bounded storage/CPU and independent opaque custody. Confirm that the desired receipt/attention semantics and transport privacy profile survive the actual composition root and platform build.

#Gate E: total maintained complexity and reversibility

Compare code that TalkCo must maintain after identity, evidence, custody and object adapters are included. A smaller custom core is not inherently preferable; an integrated engine is not inherently cheaper. Select the implementation that satisfies the declared contract with a sustainable maintenance and export path. Record the choice in an ADR, including the evidence that would reverse it.

If these gates show that the Matrix-derived path needs most of its authority and crypto integration replaced, retain the useful protocol lessons and use Matrix only at a narrower seam. If it removes substantial work while passing the relevant tests, adopt that responsibility rather than duplicating it solely to maintain a conceptual layer diagram.

#7. Highest-value additional inputs

Exact Tachyon source and build provenance: custom Rust crates/branches, OpenMLS/DMLS fork revisions, Cargo lockfile, build flags, deployment bundle hash, protocol notes and intended compatibility guarantees. The archive identifies these as missing; source symbols and reconstructed hashes cannot substitute for a maintainable source baseline.

Controlled runtime access: disposable accounts on selected Matrix homeservers, a separate federation test pair, synthetic multi-device users, and permission to capture only those test sessions. This would separate broker permissiveness from real-server behavior.

Neutrino platform evidence: the actual Android .aar/APK provenance, embedded upstream commit, feature flags, effective signing/trusted-network configuration, receipt rendering and transport settings. Source trees from different repositories must not be combined into an imaginary installed version.

TalkCo threat-model decisions: the observers against whom contexts must be unlinked, acceptable direct-link metadata, maximum tolerated stale disclosure, private authentication/evidence target, history/recovery promises and initial supported platform. Without these, testing can measure behavior but cannot determine acceptability.

Resource and custody assumptions: expected group/device counts, traffic distribution, attachment sizes, offline duration, host redundancy/leases, repair budget and energy/storage targets. The illustrative model parameters are not requirements.

Independent review scope: the coupled authorization/epoch construction, private evidence profile, key lifecycle, rollback behavior, bounded parsing/ancestry and relevant dependency/license/supply-chain review. These are separable investigations; a passing UI or documentation build does not close them.

#8. Agent handoff

The durable research starts at research-matrix-p2p.md. Detailed Matrix observations belong in the protocol chapter; integration arguments belong in the composition chapter; new empirical results belong here or in a linked dated experiment with exact commands and artifacts. Keep the comprehensive package disposition in the existing master table.

Do not silently close architecture issue #1, replace the canonical Session/TACo/Signal commitments, claim an independent audit, infer all old README statements describe current code, or relabel modeled/inherited results as fresh application execution. Update the relevant lane and owning source only when its stated evidence exists.

The user requested technical research and documentation, not product implementation. The companion script is a bounded analytical model, and the report-generation workflow is documentation infrastructure. No application, homeserver or cryptographic implementation is introduced by this evaluation.