Start by identifying the source of truth
An app can store records on the user’s computer, in an authenticated server database, or in several replicas that reconcile changes. Those are different systems, even when the interfaces look similar. The first question is which store is authoritative for the task and what should happen when another copy disagrees.
In this ecosystem, FormLogic owns its hosted business records and access rules. SoftN can keep local app data through the host-appropriate XDB surface. The XDB Rust crate supplies native SQLite storage and optional peer state. The shared names do not mean that all those records automatically participate in one network.
Do not conflate the synchronisation transports
Native XDB peer synchronisation, SoftN browser peer rooms and SoftN server synchronisation are separate paths. FormLogic’s hosted backend bridge is different again. Scope, identities, authentication and supported hosts have to be evaluated for the selected path.
For native XDB, the experimental protocol currently supports the default database and a trusted local-network model. App-scoped native files do not automatically receive equivalent peer replication. A browser using the SoftN data service does not become a native libp2p peer.
Choose the conflict model that matches the data
The current native XDB representation places a whole serialised record in each CRDT map entry. Independent records can merge, while concurrent changes to one record resolve as a whole. This is suitable for some workflows, but it should not be described as field-level collaborative editing.
For an application where two people routinely edit different fields on one record, test that exact conflict. For a critical business transition, it may be better to perform an authenticated server operation with explicit validation instead of relying on peer convergence.
An exported client is not a database backup
A .softn bundle may include source, assets and JSON collection seeds. It does not automatically include live records from a FormLogic backend or a native SQLite store. Similarly, a downloaded project and an account export may cover different parts of a deployed application.
Operators should inventory platform metadata, form response stores, hosted app databases, files and credentials, then define a consistent backup plan for the stores actually used. SQLite snapshots should include committed changes that may still be represented in the write-ahead log.
Decide what a restored replica is allowed to do
A local restore might be intended for investigation, a fork for independent work, or a replacement for all peers. These intentions need distinct operations. Otherwise an old replica can repopulate data that was deliberately removed, or a test restore can unexpectedly publish stale records.
XDB’s documented restore scopes and reset epochs address that distinction. Read the current recovery policy and exercise an interrupted restore using non-sensitive data. A backup procedure is only established when the restore path has also been tested.
Questions to answer before deployment
Where are the authoritative records? Which account or app can read and change them? What continues to work offline? What happens to concurrent edits? Does a deletion propagate? Which files are included in backup, and who can restore them? These questions are more useful than labelling the application simply “local-first”.
Use the current project guides for implementation details. Do not infer encryption, replication or access guarantees from the location of one database file or from a successful demo on a trusted network.
References & source
Read the project’s own documentation for implementation details, current releases and supported boundaries.
Project references: XDB · SoftN · FormLogic. Their project pages link to the underlying implementation documentation.
