v0.2.66

Fix: Only fire first onStream callback per stream

Root cause: Multiple onStream callbacks were registered, all receiving the same stream.
Fix: Only fire the first registered callback per stream.

v0.2.64

Fix vault key gossip: use dynamic getter for hasVaultKey instead of stale static value

v0.2.63

Bug Fix: Vault Key Gossip

Fixed a bug where vault key gossip wasn't working correctly:

Problem: Both desktop and mobile were reporting hasVaultKey=true in VERSION_INFO, even when mobile didn't actually have the vault key. This prevented the gossip mechanism from triggering.

Cause: The hasVaultKey field was set to true if pairingKeyExchange existed, rather than checking if we actually have the vault key.

Fix:

• Added cached _hasVaultKey field that tracks actual vault key status
• Status is checked when setPairingKeyExchange is called
• Status is updated when vault key is received via gossip
• Added detailed logging for debugging

Expected behavior now:

• Mobile will report hasVaultKey=false if it doesn't have the key
• Desktop will report hasVaultKey=true if it has the key
• When they connect, mobile will automatically request the key from desktop
• Logs will show: Peer vault key status: peer=true, us=false, needsKey=true

v0.2.62

Vault Key Gossip (v0.2.61)

• Vault key is now shared during regular sync sessions, not just initial pairing
• If initial pairing key exchange failed, subsequent syncs will share the key
• This fixes issues where mobile devices couldn't decrypt cloud config

Reconnection Improvements (v0.2.62)

• Faster detection: Repair stale threshold reduced from 60s to 15s
• More frequent checks: Connection repair interval reduced from 30s to 15s
• Bidirectional repair: Both peers can now initiate reconnection (with jitter to prevent collision)
• Connection timeout: 30-second timeout prevents hangs on unreachable peers
• Immediate reconnection: Transport disconnect events trigger immediate retry

Expected Impact

• Worst-case reconnection time reduced from ~90s to ~15-30s
• Many disconnection scenarios now reconnect immediately
• No more passive waiting (both peers actively try to reconnect)

v0.2.60

Add vault key diagnostic logging

v0.2.59

Improved cloud config diagnostic logging (INFO level)

v0.2.58

Diagnostic Logging for Cloud Config Sync

Added logging to help debug why cloud config isn't being picked up on some devices:

• Logs whether cloud config exists in CRDT metadata
• Logs CRDT and local timestamps for comparison
• Logs connection test results

Check the logs on mobile (Settings > PeerVault > Advanced > Copy Logs) after restarting to see what's happening.

v0.2.57

Bug Fix: Cloud Config Not Loading on Mobile

Fixed an issue where cloud sync configuration wasn't being picked up on mobile devices (or any device that already had the vault key persisted).

The Problem

When the plugin started, cloudSync.initialize() was called before the vault key was set. Since the cloud config in the CRDT is encrypted, it couldn't be decrypted and loaded without the vault key.

The Fix

After setting the vault key on startup, we now call checkForConfigUpdate() to re-check the CRDT for encrypted cloud config. This ensures devices with a persisted vault key properly load the cloud config from synced CRDT data.

v0.2.56

WebRTC In-Band Signaling

This release reimplements WebRTC signaling to use the existing sync protocol instead of a separate signaling stream, fixing reliability issues.

Changes

• WebRTC signaling via sync protocol - Signaling messages (offer, answer, ICE candidates) are now sent over the sync stream after reaching "live" mode
• Manual upgrade button - Connection status modal now shows WebRTC state and an "Upgrade" button to manually trigger direct connection attempts
• Deterministic initiator - Lower node ID always creates the WebRTC offer, preventing conflicts
• Auto-retry - Failed WebRTC upgrades automatically retry with backoff

How it works

1. Sync connection is established via Iroh relay
2. After sync enters "live" mode, WebRTC upgrade is attempted
3. If successful, data can be sent over the faster WebRTC connection
4. If WebRTC fails, sync continues over the reliable Iroh connection

v0.2.55

Full Changelog: v0.2.54...v0.2.55