The Architecture of Independence
The fundamental design constraint of the Significant Hobbies Hub is that it does not serve as a central database for the applications it connects. Each product, whether it is Kith or Anchor, retains its own interface, local data store, and immediate data authority.
Instead of synchronizing all raw records to a central schema, the Hub acts as a routing and orchestration layer. It relies on the personal-platform Cloudflare Worker and D1 database solely for providing a unified user interface, identity verification, and bounded queue management. The actual business logic and authoritative data remain within the native applications.
This separation is critical. For example, while Anchor has absorbed the planning, focus timing, and schedule review features of the previous Habits product, the Hub itself did not migrate any user data or redefine the schema. The /habits surface and typed contracts remain in the Hub solely as compatibility layers. The native apps manage the physical transition, ensuring that architectural changes at the orchestration layer do not mandate destructive migrations in the local stores.
Privacy-Safe Summaries
A core responsibility of the Hub is providing a unified view of the user's status across their portfolio of applications. However, displaying a summary does not require ingesting the underlying data.
The Hub achieves this through privacy-safe summaries. Native applications publish limited, predefined summary structures rather than their raw databases. These summaries provide just enough context for the Hub UI to render a directory card or status indicator.
Because the Hub only sees the summary—not the complete event history or raw notes—the user's detailed information remains confined to the specific application designed to handle it. This bounded sharing is essential for maintaining privacy when crossing application boundaries. The shared mirror source now supports bounded Hub batches and verified per-record acknowledgements, ensuring that summary updates are predictable and isolated.
Typed Semantic Actions
When a user needs to act on a summary—for instance, acknowledging a Kith notification or starting an Anchor focus timer from the Hub—they rely on typed semantic actions.
A semantic action is a structured, statically typed contract that defines exactly what an application can request another application (or the Hub) to do. Rather than exposing arbitrary REST endpoints or direct database access, applications expose specific, documented capabilities.
These typed contracts include summary, record, semantic-action, audit, and undo definitions. By enforcing strong types at the boundary, the Hub ensures that actions are predictable and safe. If an app requests an action, the receiving app can statically verify the shape and intent of that request before processing it.
This mechanism replaces generic API integrations with purposeful workflows. An application doesn't ask to "update row 5"; it requests a specific semantic outcome, such as "complete bucket list item," which the receiving app executes according to its own local business rules.
Concrete Examples in the Hub
The utility of typed semantic actions is visible in how the Hub manages product evolution and synchronization boundaries.
The Evolution of Anchor
Consider the evolution of Anchor. Initially, the Hub supported a separate Indulge/Habits product loop. Over time, Anchor absorbed these features to provide a more cohesive experience encompassing planning, focus timing, and schedule review.
Because the interactions between the Hub and the Habits application were defined by typed semantic actions and standardized records, this transition did not require rewriting a central database. The backend retains the habits records and callbacks as compatibility data, ensuring that older clients do not break. Anchor simply registers to handle the relevant semantic actions moving forward. The data authority remained with the apps, and the Hub only needed to adjust its routing logic.
Native Sync and Verifiable Commits
The implementation of these actions relies heavily on the PersonalSyncKit Swift package, which serves as the single native sync-client source. A critical requirement for cross-app consistency is ensuring that when a semantic action results in a data change, that change is reliably stored.
The native sync commit contract mandates that native consumers call synchronize(applyChanges:). Crucially, the application must atomically save the supplied batch in its own local store before the closure returns. If the save fails, the application throws an error, and the download metadata and cursor are not advanced.
This strict "commit before progress" semantic ensures that the Hub never considers a record acknowledged until the owning app has durable, physical proof of the change. Failed bookkeeping writes retain the prior in-memory state, preventing corrupt synchronization logic from discarding ownership or tombstone history.
Data Authority and Synchronization
Managing state across multiple independent stores introduces significant complexity around identity and recovery. The Hub addresses this through explicit account isolation and opt-in recovery mechanisms.
Account Isolation and Ownership
The shared queue architecture must strictly separate data belonging to different verified accounts. The runtime stores a stable server-verified account ID alongside its queue. Before a native app can upload data, it must ask the user to approve which verified Hub account owns the local document, and bind the runtime using bindAccount(account, adoptingUnownedData: true).
The runtime requires explicit adoption of unowned data and aggressively rejects attempts to bind a different account to an existing queue. It rechecks the captured session around transport and app commits, protecting account UI state from older callbacks. This source-level identity protection ensures that semantic actions initiated by Account A cannot inadvertently manipulate records belonging to Account B.
Opt-in Download Recovery
If a local database is lost or corrupted, applications need a way to recover previously acknowledged records without resetting owner state. The Hub provides an opt-in native replay API (synchronize(account: account, replayFromStart: true, applyChanges: ...)).
This allows compatible callers to read historical pages from zero. Because the caller must still preserve newer local edits and local tombstones, this replay mechanism acts as a controlled historical sync rather than a destructive state replacement. The cursor never moves backward, and the system relies on the latest-version precedence to resolve conflicts cleanly.
Conclusion
Building cross-app personal workflows does not require sacrificing local data authority or privacy. By utilizing typed semantic actions and privacy-safe summaries, the Significant Hobbies Hub demonstrates that independent applications can participate in a unified ecosystem.
Through rigorous synchronization contracts, explicit account isolation, and bounded queue management via PersonalSyncKit, the Hub provides a durable architectural pattern for personal software. It proves that applications can work together seamlessly while remaining physically and logically distinct.
Next Action
To understand the mechanics of verifiable local commits and bounded queue management, review the synchronize(applyChanges:) implementation in the PersonalSyncKit repository. Ensure any new native consumer integrates the durable ownership checks before migrating from legacy return-only sync paths.