Open Local First / FOSDEM 2026 project scan

The source schedule is Open Local First — Devroom Schedule, for the FOSDEM 2026 Local-First, sync engines, CRDTs devroom on 2026-02-01. Primary project documentation and current repositories were checked where the talk exposed an implementation or architecture claim. Existing TalkCo research was treated as the baseline so this page records deltas rather than repeating the whole inventory.

#What changed after the schedule scan

The conference does not point to one replacement stack. It strengthens four seams already present in TalkCo:

1. Authorization must be replicated deliberately, not inherited from transport. Keyhive, Meadowcap, p2panda-auth, NextGraph capabilities, and Spritely's capability/CRDT composition all treat access state as first-class distributed state. They differ sharply in identity, delegation, revocation, evidence, and maturity.
2. Network-optional delivery is broader than one carrier. p2panda and Willow explicitly support heterogeneous delivery, including local links and improvised/offline transport. Teamtype similarly treats editor integration as a protocol boundary over a replaceable collaboration engine.
3. Production local-first failures live above the CRDT. Plane, Teleportal, LaSuite Docs, and the local-first UX talk all surface suspend/resume, server-originated changes, snapshots, permissions, partial availability, retry visibility, and metadata leakage as application problems.
4. Replication should be narrower than the data model when possible. SQLRooms' split between read-only/queryable source data and collaborative CRDT state is a useful architectural pattern. Flec/ECRO/VeriFx reinforce the inverse rule: when an invariant cannot be made coordination-free, synchronize that invariant rather than hiding the requirement in merge code.

#Schedule coverage and TalkCo disposition

#High-value protocol and library findings

#Willow is the most relevant new protocol-family deepening

Willow now deserves a more explicit place in the comparison than a single Meadowcap row. Its specifications deliberately split several jobs TalkCo also needs to keep separate:

• the Willow data model gives structured names to bytestrings;
• Meadowcap provides attenuable read/write capabilities over areas of a namespace;
• Confidential Sync aims to synchronize without revealing unrelated namespace/subspace/path interests to an unauthorized peer;
• the Drop Format packages verifiable entries and payload slices so data can travel asynchronously over arbitrary channels rather than requiring an always-available rendezvous/sync service;
• the Transfer Protocol gives a simpler request/response path;
• Bab supplies verifiable payload-slice structures used by the drop work.

Primary sources: Willow specifications, Meadowcap, Confidential Sync, and Drop Format.

The fit is architectural, not wholesale. TalkCo needs contextual identities, deniable/private authentication profiles, message/publication semantics, revocation expectations and social access rules that Willow does not decide. A Meadowcap token is also transferable capability evidence by design; that is not automatically the correct evidence profile for private TalkCo relationships.

Useful experiment: represent one TalkCo shared-object namespace and one private context in a Willow/Meadowcap fixture, then measure what namespace/path/membership information each peer and transport sees. Repeat the same payload via Confidential Sync and a Drop carried over an ordinary file/message transfer. The experiment advances only if it preserves the #3/#4 authentication and anti-correlation requirements.

#Keyhive is closer to executable research, but remains pre-alpha

The current Keyhive repository exposes a Rust workspace with beelay-core for authorization-aware sync over E2EE data, keyhive_core for signing/encryption/delegation, and keyhive_wasm for browser bindings. Its README explicitly warns against production use, calls the release pre-alpha, expects unstable APIs, and says it has not undergone a security audit. September 2026 pull requests are actively changing concurrent-add, revocation, membership and delegation behavior.

Primary sources: Keyhive repository and Keyhive pull requests.

This is exactly the kind of project TalkCo should learn from without prematurely freezing around it. The right question for #5 is not "Keyhive or p2panda-auth?" but whether the common fixture can express removal, concurrent membership, late history and offline authority under each model without creating a global user root or a status-bearing trust graph.

#NextGraph is a useful integrated counterexample to both "assemble everything" and "one engine solves everything"

NextGraph's Rust implementation combines permissioned P2P repositories, E2EE, local storage, CRDT support (including Yjs/Automerge and RDF-oriented data), semantic links, and TypeScript/React/Svelte/Vue/Python bindings. It is explicitly alpha. Its integration value is highest where TalkCo would otherwise need to assemble the same seams.

Primary sources: NextGraph Rust repository, framework CRDT docs, and crate documentation.

The boundary review should concentrate on stable repository/document identifiers, broker visibility, membership/permission granularity, key rotation, cross-document links, and whether public-key signatures or semantic links become correlation handles across TalkCo profile spheres. The research target is a bounded integrated countercandidate, not a commitment to RDF or DIDs.

#Spritely's Brassica Chat is a particularly clean authority-composition reference

Spritely's prototype combines two authority shapes instead of pretending one mechanism does both jobs: object capabilities/actors govern behavior, while operation-based CRDTs plus authorization certificates govern replicated data. The prototype uses separate CRDT actors for chat logs, profiles, and certificates, and explicitly considers Byzantine divergence.

Primary sources: Composing capability security and CRDTs and Goblins.

TalkCo should borrow the separation, not the Scheme runtime. It reinforces the existing distinction among identity evidence, an action grant/capability, a content-key envelope, and storage custody. It also suggests a useful #5 test: authorization-state CRDT failure must not silently turn a valid content merge into a valid authority transition.

#p2panda remains one of the best substrate experiments for heterogeneous connectivity

The Modal/Reflection talk makes the goal concrete: applications should be able to work across Internet infrastructure, Bluetooth, Wi-Fi Direct/Aware and even offline transfer while exposing common connectivity/discovery/sync/encryption/access-control building blocks. Reflection is also valuable as a native GTK reference app rather than as a TalkCo dependency.

Primary sources: p2panda, p2panda access control, and Reflection.

The caution already recorded in TalkCo remains: p2panda-auth's cumulative role model and the substrate's author/topic/discovery identifiers must not become TalkCo's social role hierarchy or profile identity. The networking value is strongest if #9 can run the same fixture over multiple p2panda transports without changing application authorization outcomes.

#Object, provenance, and collaboration lessons

#Radicle shows how social artifacts can live beside user-owned data

Heartwood treats issues, patches and identities as replicated Collaborative Objects associated with a repository. The useful idea for TalkCo is not Git specifically; it is that social collaboration artifacts can be local, versioned protocol objects rather than records owned by a SaaS database.

Primary source: Radicle protocol guide.

The mismatch is equally useful. Radicle relies on signed histories, stable repository identifiers and gossip. Those properties are appropriate for code provenance but conflict with TalkCo's default private-deniable contexts and anti-correlation goals. #2 should therefore use Radicle as a comparison for object ancestry and extensible collaborative object types, while #3 treats its evidence model as a deliberate-attestation profile rather than the private default.

#Teamtype's CEP proposal is an interface pattern worth retaining

Teamtype's proposed Collaborative Editing Protocol tries to do for editor collaboration what LSP did for language tooling: let an editor implement one collaboration-facing protocol while multiple engines/servers implement the other side. The post-FOSDEM working notes explicitly discuss JSON-RPC/msgpack-RPC, LSP extension, Braid-HTTP, position units, versioning and the risk of premature standardization.

Primary sources: FOSDEM Teamtype talk and CEP working notes.

TalkCo does not need to adopt CEP now, but #10 should preserve the same seam: rich-text/editor integration should not be fused to one CRDT, transport, or storage provider. That would make later BlockNote/ProseMirror/native editor experiments cheaper and reduce pressure to make editor-specific event shapes canonical protocol objects.

#SQLRooms supplies a useful negative-space rule: synchronize state, not everything

SQLRooms uses DuckDB as a local/read-only query engine while collaborative Loro state covers queries, notebook/canvas layout, annotations and comments. The source data need not be replicated through the CRDT.

Primary sources: SQLRooms and SQLRooms repository.

TalkCo can apply the same test broadly: before putting a blob, archive, media timeline or large derived view inside a CRDT, ask whether peers only need a stable reference plus small collaborative state. This is especially relevant to channels with large attachments, shared community materials, and query/index projections.

#Flec, ECROs and VeriFx strengthen the "coordination where the invariant demands it" rule

The VUB work is useful less as a dependency and more as a methodology. Flec makes network/security/authorization constraints explicit while developing RDTs. ECRO-style work derives replicated behavior from sequential definitions, and the conference explicitly notes that some invariants cannot be guaranteed under coordination-free CRDT semantics; those cases require mixed consistency. VeriFx adds automated correctness verification for RDTs and has a published artifact.

Primary sources: FOSDEM replication talk and VeriFx paper/artifact.

This is directly relevant to TalkCo's shared-record work. Membership, key rotation, irreversible custody changes and some community-root operations should not be forced into a CRDT merely to maintain a "fully local-first" label. #5 should document which invariants are mergeable and which deliberately fail closed or require fresh authority.

#Production and UX lessons

#Plane turns several abstract failure cases into concrete client tests

Plane's conference description identifies six production problems around Yjs: server-originated edits alongside live edits, synchronization infrastructure at scale, very large documents, version history via StateVectors/StructStore, resume after browser tab suspension, and realtime permission/comment changes.

Primary source: Open Local First schedule — Plane talk.

The TalkCo fixture should cover the same classes without copying Plane's server model:

• a local edit races with a machine/automation-originated accepted change;
• an app process is suspended/killed, then resumes from stale local state;
• snapshots/checkpoints remain explainable after compaction;
• access is removed while an offline writer has pending changes;
• a large object does not require loading or retaining all history in UI memory.

#Yjs 14's attribution machinery is useful UI metadata, not identity proof

As of the releases checked on 2026-09-22, Yjs v14.0.0-rc.24 is still a prerelease while v13.6.31 is listed as the latest stable release. The v14 branch adds IdMap/IdSet attribution machinery that can associate changes with metadata such as creator and time.

Primary sources: Yjs releases and Yjs attribution design.

TalkCo should distinguish three concepts:

• change attribution for local/editor UX;
• authenticated authorship in a shared context;
• transferable proof of personal authorship.

Yjs can help the first. It does not decide the latter two, and storing exact actor/time attribution may itself conflict with deniability, retention or context-minimization goals.

#Teleportal is a useful example of content E2EE without metadata confidentiality

Teleportal is modular across storage, transport and JS runtime, implements Yjs sync, files, snapshots and multiple transports, and is MPL-2.0. Its current README states that AES-GCM encrypts user content while CRDT metadata remains plaintext so the server can merge, synchronize and attribute edits.

Primary source: Teleportal repository.

That can be a reasonable design for many applications, but it demonstrates why TalkCo cannot test "encrypted" as a boolean. #9/#13 should enumerate which identifiers, state vectors, authorship metadata, document membership, access patterns and timestamps remain visible for each adapter.

#The local-first UX talk should become a fixture checklist

The conference UX session names four user-visible conditions that are easy to omit from protocol testing: replacing stale data without disorientation, explaining partial offline availability, showing actions that are queued or incomplete, and attributing remote changes without disruption.

TalkCo's client should therefore distinguish at least:

• saved locally;
• accepted into shared state;
• delivered/replicated to a named durability target;
• waiting because a current capability/network/freshness requirement is missing.

This fits the existing #10 requirement that locally saved, shared-state accepted and backed-up states remain distinct. It also prevents local-first from turning invisible retry machinery into a new source of uncertainty.

#LibreOffice Writer illustrates bounded adoption

The Writer prototype applies yrs only to comments while the rest of the document stays read-only. This is a useful pattern for TalkCo: integrate a CRDT first around the object class that actually benefits from concurrent merges rather than converting an entire mature content model at once.

Primary source: Open Local First schedule — LibreOffice Writer talk.

#Miru is a future media-domain reference, not a current stack candidate

Miru is an AGPL-3.0, local-first, self-hostable web media editor. Its FOSDEM talk focuses on the mismatch between rich-text assumptions and nonlinear video-timeline collaboration.

Primary sources: Miru and FOSDEM Miru talk.

The main TalkCo lesson is to avoid assuming that one generic sequence/text CRDT covers every future rich-media artifact. If collaborative media editing becomes product scope, research the timeline model then; do not put Miru on the current core path.

#Application and ecosystem case studies

#LaSuite is most relevant as a reusable UX/component and licensing case study

LaSuite Docs is a large collaborative application built with Django/React, BlockNote, Hocuspocus and Yjs. It supports offline edits and granular sharing, and the conference specifically points at its reusable UI Kit and sharing/search patterns.

Primary source: LaSuite Docs repository.

The implementation also provides a good supply-chain example: advanced BlockNote XL features are AGPL-3.0 and are excluded from MIT-compatible builds using a build flag. #10/#13 should therefore test feature-level transitive licensing rather than recording only the top-level project license.

#Seed Hypermedia deserves a privacy-regression case study

Seed combines local-first publishing, versioned/provenance-oriented documents and community/space concepts. Its recent development is active. On 2026-09-08, release 2026.9.3 stated that private-document creation was temporarily disabled while an access-exposure problem was contained; later releases continued rapidly.

Primary source: Seed releases.

That incident is more useful to TalkCo than a feature checklist. The common fixture should verify that every creation/import/republish/comment/agent path preserves the expected access profile, and a release gate should be able to disable a risky private-content path without losing public/non-sensitive operation. Seed's public Explore/feed concepts are product choices TalkCo does not inherit.

#PouchDB/CouchDB remain operational benchmarks

The conference deliberately highlights that local-first does not require a CRDT: PouchDB provides local storage and replication to CouchDB with explicit conflict handling. The long-running projects also foreground governance and high-stakes deployments under intermittent connectivity.

Primary sources: PouchDB and Apache CouchDB.

TalkCo already keeps them as replicated-database benchmarks. The new value is to keep long-term governance/maintenance quality in #13's adoption gate alongside technical fit.

#Security and validation deltas

#OrbitDB's current encryption issue should become a regression test pattern

An open OrbitDB issue filed 2026-06-19 reports that the Documents store in @orbitdb/core 3.0.2 silently forwarded the wrong option name and therefore could write/read plaintext even when data/replication encryption was configured. The report includes a reproducer and notes that other store types behaved differently.

Primary source: orbitdb/orbitdb#1253.

This is not evidence that OrbitDB is generally unsafe. It is evidence that TalkCo's fixture must verify confidentiality for every concrete store/object path rather than checking that "encryption was configured." The same test belongs to any selected database/provider.

#Production adoption must keep project generation and version in the evidence

Jazz Classic versus Jazz v2, Yjs v13 versus v14 prerelease, and Teleportal's explicitly work-in-progress E2EE show the same failure mode: a project name is too coarse to carry a security or authority claim. The master table should retain exact generations and the adoption record should pin revisions.

#Proposed experiments added to existing lanes

No new top-level lane is needed. The conference work fits the existing decision partition:

• #2 Object protocol: compare Radicle Collaborative Objects, Willow entries/namespaces, and a Teamtype-style editor boundary against TalkCo's portable-private-object requirements.
• #4 Identity: inspect Keyhive, NextGraph and Willow capability/identity bindings for cross-context correlation and recovery.
• #5 Collaboration: add Keyhive revocation/concurrent-membership cases, Willow authorization state, SQLRooms state/data separation, Yjs attribution privacy, and Flec/VeriFx mixed-consistency reasoning.
• #9 Networking: test p2panda heterogeneous delivery and Willow Confidential Sync/Drop against the same observer model; treat Teleportal only as a web-server/provider benchmark.
• #10 Client: add Plane suspend/resume and server-originated-change cases; assess BlockNote/LaSuite UI/editor reuse and Teamtype's editor/engine separation.
• #13 Validation: add per-object encryption assertions, private-path regression tests, exact generation/revision pins, and transitive-license checks.

#Evidence boundary

This scan is current to 2026-09-22 where current upstream state was material. It is not a package security audit. Conference descriptions are treated as claims or implementation reports, not independent proofs. Repository issues are evidence of a specific reported failure until reproduced; they do not justify blanket security labels. Pre-alpha/RC status is recorded because it changes the adoption gate, not because immature software is intrinsically irrelevant.

The durable candidate overview remains the master research table. This page keeps the conference-specific evidence and rationale so the master table can stay skimmable.