Connect an app
Pair a compatible app with a code. You control which apps can share data and which services they may use.
Personal Node · Experimental alpha
A home for your apps’ shared data.
Your apps keep their own data and work independently. Personal Node is their desktop companion: it keeps a copy of the data they share, shows what has synced, and lets you browse saved notes and reports. We recommend this architecture when an app needs another data copy or needs to make shared data available while the original app is closed.
Available for source experimentation, outside the core supported preview. Signed distribution, real-model platform acceptance, and the full linking and recovery journey remain release gates.
A simple desktop home
See your apps. Read what they’ve shared.
Know what is copied
See connection and copy status separately. An app can be closed while its last verified copy stays available on the node.
Browse your saved content
Read notes and reports as friendly cards. Developers can switch to Advanced for complete records and technical details.
Recommended companion architecture
Local first. Another copy when connected.
Build basic use around the app’s own storage. Add Personal Node for selected data copies and permitted services. Compatibility is an explicit integration; generated or existing apps do not connect automatically.
Your notes app
Own interface · Own local data
Works without the node
Your reports app
Own interface · Own local data
Works without the node
Selected data
with permission
with permission
Your Personal Node
- Keeps verified copies of shared data
- Shows what has synced
- Lets you browse saved content
- Serves copied data to permitted, compatible apps
Verified copies today
The node can verify the last shared version of supported data. Notebook and Briefing have been tested with actual desktop pairing, offline edits, reconnection, and access to copied notes while Notebook is stopped. These tests ran on one computer.
Full backup and recovery are still ahead
Sync is not a complete backup service. Retention, restoring lost app data, and the full device-linking journey remain unfinished. Separate-device operation needs further acceptance testing. Keep an independent backup for important data.
Two ways to build. Shared foundations.
Your product chooses the experience.
Connect your app
Keep your app’s own interface and local storage. Pair its compatible P2P runtime with Personal Node, declare the resources to replicate, and request only the services it needs. The desktop owner approves access.
Build your own desktop app
Use the desktop source as an architectural reference: an Electron interface, a restricted IPC bridge, and a Bare worker for P2P and inference. Compose the shared library and optional services around your own product.
Share across apps by agreement
Publish a versioned data or service contract that other apps can implement. Pair peers and grant specific methods. Each app keeps its own interface and business logic; compatible services can run in your app or another trusted host.
The stack is not tied to one app category: notes, catalogs, creative tools, and other products can use the same foundations. Compatibility requires an integration in a supported runtime; arbitrary existing apps and browser-only code do not connect automatically. The desktop source is a reference composition, not a one-command white-label template.
What compatibility means
Shared protocols are the beginning.
- 1. Keep local ownership. Your app owns its storage, schemas, migrations, and offline behavior. Networking adds services when a peer is available.
- 2. Declare data explicitly. Replicate supported Hypercore, Hyperbee, or Hyperdrive resources. Agree on schema versions, encryption access, and writer rules before another app interprets or edits them.
- 3. Share functionality deliberately. Define versioned capabilities with validated inputs and outputs. A matching contract does not grant permission; access still requires pairing and method grants.
- 4. Test independence and reconnection. Handle denied access, missing peers, cancellation, and incompatible versions. Avoid replaying mutations blindly after a disconnect.
Try Notebook and Briefing, two command-line source examples. Briefing calls Notebook’s summary service through a shared contract, then builds its own report from replicated notes. Tests cover a restarted desktop worker serving notes while Notebook is stopped, plus real dashboard pairing, verified copies, and updated reports on one computer. Personal Node hosts the data; live Notebook service calls still need Notebook running.
Current scope
Useful foundations. More work before everyday use.
Implemented in the alpha
Simple Home and Advanced views, app pairing and permissions, verified copies, readable note and report cards, storage limits, and pause/resume controls. Notebook and Briefing demonstrate shared data and a versioned service contract on one computer. Optional AI controls exist; real-model acceptance is separate.
Next priorities
A complete device-linking journey, recovery and retention controls, clearer failure recovery, real-model and signed installer acceptance, and extending the two-app proof to physical devices and desktop interfaces.
A verified replica covers an observed checkpoint, not guaranteed future writes or full recovery. Settings export includes sensitive identity material in plaintext and excludes app payloads. Removing an app revokes access but leaves downloaded blocks; per-app purge is not implemented. Collaborative database hosting with Node sync is not yet a supported combination.
Read the current Personal Node boundaries