Skip to content

fix(moss): persist node identity (v0.2.2)#8

Merged
ForeverInLaw merged 2 commits into
mainfrom
fix/moss-identity
Jun 2, 2026
Merged

fix(moss): persist node identity (v0.2.2)#8
ForeverInLaw merged 2 commits into
mainfrom
fix/moss-identity

Conversation

@ForeverInLaw

Copy link
Copy Markdown
Contributor

Bug

After restart, peers flap (peer_joined/peer_left repeatedly) and the connection never establishes.

Root cause

moss-ffi delegates its node identity load/save to host keystore callbacks (Moss_SetKeyStore). mosh listed the symbol as required but never called it, so moss's load/save pointers stayed nil and resolveIdentity() minted a fresh random libp2p identity on every launch. After a restart our peer-id changed; the remote kept the stale entry → connection churn.

Fix

  • New MossKeyStore trait backed by the encrypted redb store (moss_identity table, AES-256-GCM + keychain DEK).
  • extern "C" load/save callbacks (probe-then-copy protocol) + install_keystore() bound to Moss_SetKeyStore.
  • Registered once in PrivateDmState::ready before any node starts (incl. rehydrate). Ephemeral fallback in in-memory mode.
  • Bump to v0.2.2 + CHANGELOG.

Tests

  • persistence::moss_identity_round_trips
  • moss_ffi::keystore_callbacks_round_trip_identity (probe/buffer protocol vs mock store)

Local: fmt ✓ · clippy -D warnings ✓ · nextest 64 passed (1 unrelated flaky recovered), 0 failed.

🤖 Generated with Claude Code

The Moss node's libp2p transport identity was regenerated on every launch:
moss-ffi delegates identity load/save to host keystore callbacks, but mosh
never registered them (Moss_SetKeyStore was listed as a required symbol yet
never called), so resolveIdentity() minted a fresh random identity each start.
After a restart our peer-id changed, a connected peer kept the stale entry, and
the connection flapped (rapid peer_joined/peer_left) instead of re-establishing.

Wire a MossKeyStore trait backed by the encrypted redb store (new moss_identity
table, AES-256-GCM like everything else), register it and call install_keystore
once in PrivateDmState::ready before any node starts. The identity is now stable
across restarts. Falls back to an ephemeral identity in in-memory mode.

Tests: persistence round-trip for the identity row, and the probe-then-copy
keystore callback protocol against a mock store.
@ForeverInLaw ForeverInLaw merged commit 57a2804 into main Jun 2, 2026
2 checks passed
@ForeverInLaw ForeverInLaw deleted the fix/moss-identity branch June 2, 2026 20:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant