Cross-device vault sync: local edits, CRDTs and remote storage

The Cloud Dependency Problem

Cross-device synchronization needs a way to locate, fetch and merge encrypted updates. Peer-to-peer addressing changes that path; it does not remove every operator or availability dependency. This article separates local edits, merge rules and remote storage.

Why P2P Sync Matters in 2026

A developer may use a phone and several computers. Sync needs a tested path for those devices and their network conditions. A generic average device count does not establish the best topology.

Benefits compound:

• Zero trust architecture by default
• Works offline when devices are on same network
• No subscription fees for server infrastructure
• Resistant to corporate data breaches
• Geographic independence

How P2P Password Sync Works

Cross device sync without cloud relies on three core technologies: content-addressed storage, conflict-free replicated data types (CRDTs), and peer discovery.

Device A ←→ IPFS Network ←→ Device B
   ↓           ↑               ↓
 Local      Content Hash    Local
 Vault    → (immutable) ←   Vault

Content addressing means data gets identified by its cryptographic hash, not location. When you update a password, the change gets a new hash. Other devices can fetch this hash from any peer that has it.

CRDTs handle concurrent edits without conflicts. If you update your GitHub password on your phone while updating your AWS password on your laptop, both changes merge automatically. No "last writer wins" data loss.

Technical Implementation

IPFS provides the distributed storage layer. Each password vault entry becomes an IPFS object:

interface VaultEntry {
  id: string;
  encryptedData: Uint8Array;
  timestamp: number;
  deviceId: string;
  signature: Uint8Array;
}

Devices announce their vault state using IPNS (InterPlanetary Name System). Each device publishes a signed pointer to their latest vault head:

interface VaultHead {
  version: number;
  rootHash: string;
  lastModified: number;
  deviceSignature: Uint8Array;
}

Other devices subscribe to these IPNS names and pull updates. The CRDT ensures all devices converge to the same state regardless of network partitions or update ordering.

VaultKeepR's P2P Architecture

The client encrypts vault snapshots before upload. Storage can involve IPFS gateways, pinning services, hosted APIs and S3-compatible backends. These services handle ciphertext, while timing, size, CIDs and on-chain activity may remain observable. IPFS content addressing does not guarantee persistence: retain an independent encrypted backup and test retrieval. The sync documentation and threat model describe those dependencies.

Shamir recovery protects a vault key and is not the mechanism of ordinary synchronization. The code examples above illustrate a design, not complete released VaultKeepR APIs.

Implementation Steps

Building cross device sync without cloud requires careful protocol design:

1. Choose Your Storage Layer IPFS offers the most mature P2P storage, but alternatives exist. OrbitDB builds databases on IPFS. Gun.js provides real-time sync. Hypercore uses append-only logs.

2. Handle Network Partitions Devices go offline. Networks split. Your CRDT must handle arbitrary partition scenarios. Test with simulated network failures.

3. Optimize for Mobile Battery and bandwidth matter. Implement incremental sync, compress payloads, and batch network operations. Mobile devices should be sync clients, not full IPFS nodes.

4. Plan Your Security Model End-to-end encryption is non-negotiable. Device authentication prevents unauthorized sync participation. Forward secrecy protects historical data if current keys get compromised.

Performance Trade-offs

Cross device sync without cloud isn't universally faster. Initial sync can be slower since devices must discover peers and exchange full state. Subsequent syncs are often faster because devices maintain direct connections.

Storage overhead increases. IPFS adds metadata to each object. CRDTs store operation history. Expect 2-3x storage usage compared to centralized systems.

Battery usage varies by implementation. Well-optimized P2P sync uses less battery than constantly polling cloud APIs. Poorly optimized P2P sync drains batteries quickly.

Security Considerations

P2P networks expose new attack vectors. Malicious peers can flood your device with garbage data. Sybil attacks create fake peers to isolate your device. Traffic analysis reveals sync patterns even with encryption.

Mitigation strategies:

• Rate limit incoming connections
• Verify peer authenticity before sync
• Use onion routing for metadata privacy
• Implement reputation systems for peer selection

The Future of Decentralized Sync

Cross device sync without cloud represents the first step toward truly private digital infrastructure. Password managers pioneer these techniques, but the same patterns apply to documents, photos, and application data.

WebRTC support in all major browsers enables P2P web applications. Progressive Web Apps work offline and sync when connected. The technical foundation for post-cloud computing already exists.

Try VaultKeepR for cross-device sync with client-side encryption and no vault server to administer, and see where hosted gateways, pinning, and API services still fit in. Your passwords stay yours.