keyFor currently ignores publicKeyHex (String get keyFor => _keyPrefix;), so discovered contacts will still be persisted under a shared key across companions. This defeats the PR’s isolation goal; update keyFor to incorporate the truncated public key (consistent with other stores).

saveContacts does not guard against an unset publicKeyHex, unlike loadContacts. Once keyFor is made companion-specific, saving before setting the key would write to an empty-suffix key (or the wrong namespace) and can reintroduce data bleed; add the same early-return/log guard used by the other stores.

saveMessages/loadMessages now use keyFor (includes publicKeyHex), but clearMessages still removes '$_keyPrefix$contactKeyHex' (old/global key). This means removing a contact won’t clear its persisted conversation for the current companion, and may delete legacy/other-companion data instead; update clearMessages to use the same namespaced key as save/load (and apply the same empty-key guard).

Several stores use publicKeyHex = value.length > 10 ? value.substring(0, 10) : ''. Using > 10 drops the key when the input is exactly 10 hex chars, and using '' for shorter values causes silent no-ops plus repeated warnings. Prefer >= 10 (or min(value.length, 10)) and consider keeping a shorter prefix rather than clearing it so the store remains usable in edge cases/testing.

clearAllChannelMessages filters prefs.getKeys() with startsWith(keyFor). If publicKeyHex hasn’t been set (so keyFor is just _keyPrefix), this will match and remove all channel message keys for all companions. Ensure you bail out when publicKeyHex is empty (similar to loadChannelMessages) to avoid unintended data loss.

This screen creates/uses a CommunityStore, but after this PR CommunityStore won’t load/save unless setPublicKeyHex is called. You’ve set the key for ChannelMessageStore here; do the same for _communityStore (and any other per-companion stores used by this screen) to avoid communities silently not persisting.

After setting the stores’ publicKeyHex, you reload several persisted datasets but not discovered contacts. Since loadDiscoveredContactCache() isn’t called elsewhere, add it here so the discovery list is restored per companion. Also, because _loadChannelOrder() now depends on publicKeyHex, consider removing the earlier _loadChannelOrder() call in initialize() to avoid warning logs and double-loading.

CommunityStore now hard-requires publicKeyHex to be set (otherwise load/save no-op). Current call sites that construct CommunityStore() (e.g. ChannelsScreen / CommunityQrScannerScreen) don’t set it, so communities will stop persisting/loading after this change. Either plumb the companion key into these screens (or accept it in the constructor) and ensure it’s always set before any operation.

setPublicKeyHex uses value.length > 10, which clears publicKeyHex when the input is exactly 10 chars (the intended prefix length). Accept >= 10 (or clamp via min).

This store switched from the legacy key (communities_v1) to a scoped key (keyFor). Without a migration, existing users will appear to lose stored communities after upgrading. Consider migrating/copying the legacy value into keyFor the first time you load for a given publicKeyHex.

setPublicKeyHex uses value.length > 10, which clears publicKeyHex when the provided value is exactly 10 chars (the intended 5-byte prefix). Accept >= 10 (or clamp).

These Future-returning load methods are called without await/unawaited. The repo already uses unawaited(...) elsewhere, so this likely triggers unawaited_futures warnings and makes sequencing less explicit. Wrap these calls in unawaited(...) (or make _handleSelfInfo async and await them).

setPublicKeyHex currently clears publicKeyHex unless value.length > 10. This rejects exactly-10-char prefixes (the intended 5 bytes) and can leave the store unscoped. Use a condition that accepts length 10 (and ideally derive the prefix via min(value.length, 10)).

keyFor now scopes message storage by companion, but clearMessages() in this class still removes the legacy unscoped key ($_keyPrefix$contactKeyHex). This means scoped messages won’t be cleared (and could also delete another companion’s legacy data). Update clearMessages() to use the same scoped key as saveMessages/loadMessages and add the same publicKeyHex guard.

setPublicKeyHex uses value.length > 10, which will set publicKeyHex to empty when the provided value is exactly 10 chars (the intended 5-byte / 10-hex-char prefix). Accept >= 10 (or clamp via min).

setPublicKeyHex currently requires value.length > 10, which rejects exactly-10-char prefixes and leaves the store unscoped. Since the intended prefix is 10 hex chars, accept >= 10 (or clamp).

setPublicKeyHex currently requires value.length > 10, which rejects exactly-10-char prefixes and leaves this store unscoped. Since the intended prefix is 10 hex chars, accept >= 10 (or clamp).

clearChannelMessages doesn’t guard against an empty publicKeyHex. If it’s unset, this can delete unscoped (shared) channel message data. Add a guard similar to loadChannelMessages() to prevent deletions when the store isn’t scoped.

Keep message deletion key format consistent

This change namespaces saved messages with keyFor, but clearMessages in the same class still deletes $_keyPrefix$contactKeyHex (without the companion prefix). When MeshCoreConnector removes a contact and calls clearMessages, the newly saved per-companion conversation is left behind and can reappear on next load, so delete semantics are now broken for all contacts saved after this refactor.

Useful? React with 👍 / 👎.

Initialize CommunityStore namespace before enforcing guard

CommunityStore now returns early whenever publicKeyHex is unset, but no call site sets setPublicKeyHex before using it (e.g. community load/add flows in ChannelsScreen and CommunityQrScannerScreen). That makes loadCommunities always return [] and saveCommunities no-op, so creating/joining/managing communities no longer persists after this commit.

Useful? React with 👍 / 👎.

Initialize ContactGroupStore key before load/save

ContactGroupStore now hard-fails reads/writes when publicKeyHex is empty, but the ContactsScreen usage never sets setPublicKeyHex. As a result, group data always loads as empty and save operations are dropped, so contact grouping persistence is effectively disabled by this change.

Useful? React with 👍 / 👎.

clearAllChannelMessages filters keys with startsWith(keyFor). If publicKeyHex is empty (because setPublicKeyHex hasn’t been called yet), keyFor becomes just the base prefix and this will match/remove all channel message keys across companions. Add the same publicKeyHex.isEmpty guard used in the load/save methods before iterating/removing keys.

initialize() calls _loadChannelOrder() before setPublicKeyHex is applied to the stores (this only happens later once self info is available). With the new store guards, this first load will return an empty order (and log warnings), then notify listeners, and later reload again once self info arrives—potentially causing unnecessary UI churn/flicker. Consider deferring _loadChannelOrder() until after the stores are scoped to selfPublicKeyHex (or make the stores tolerate an unset key without logging/overwriting state).

selfPublicKeyHex currently allocates a new Uint8List(0) every time the getter is called when _selfPublicKey is null. Since this getter may be read frequently during widget rebuilds, consider avoiding the allocation by explicitly returning '' when _selfPublicKey == null (or caching the computed hex string when the self key is set).

loadGroups() reads from _keyPrefix instead of the scoped keyFor, and the migration path reads/removes _keyPrefix again. After migration, future loads won't read the scoped value written under keyFor, effectively dropping persisted groups. Read from keyFor first, then fall back to legacy _keyPrefix for one-time migration.

loadCommunities() reads from _keyPrefix instead of the scoped keyFor, and the migration path reads/removes _keyPrefix again. After migrating, subsequent loads won't read the scoped key, so communities appear to disappear. Read from keyFor first, then fall back to legacy _keyPrefix for one-time migration.

loadChannelOrder() reads from _keyPrefix ("channel_order_") rather than the scoped keyFor, and the migration also reads/removes _keyPrefix. This both (1) prevents loading the scoped value stored under keyFor, and (2) won't migrate the real legacy key (previously channel_order). Read from keyFor first, and migrate from the old constant key name.

loadChannelMessages() fetches from prefs.getString(_keyPrefix) instead of prefs.getString(key) (scoped per channel). The migration path also reads/removes _keyPrefix rather than the per-channel legacy key (e.g. channel_messages_<index>). This means scoped messages will never load after migration. Read key first and migrate from the correct per-channel legacy key.

clearChannelMessages() does not guard against an unset publicKeyHex. With an empty publicKeyHex, $keyFor$channelIndex collapses to the legacy prefix and can remove another companion's data. Add the same publicKeyHex.isEmpty early-return guard used by the other methods in this store.

loadContactUnreadCount() reads from _keyPrefix instead of the scoped keyFor, and the migration path also reads/removes _keyPrefix again. After the legacy key is removed, subsequent loads will never read the data written under keyFor, effectively losing unread state. Read from keyFor first, then fall back to the legacy _keyPrefix key for one-time migration.

loadChannels() reads from _keyPrefix instead of the scoped keyFor, and the migration path reads/removes _keyPrefix again. This prevents loading channels stored under keyFor after the first migration. Read from keyFor first, then fall back to the legacy _keyPrefix key for one-time migration.

clearAllChannelMessages() now filters keys by keyFor. If publicKeyHex is unset, keyFor collapses to the legacy prefix and this method will delete all channel message keys across companions. Add a publicKeyHex.isEmpty guard (consistent with save/load) before enumerating/removing keys.

The migration log message says "Migrating channel messages" but this store migrates contact groups; the message should reflect the data type being migrated.

The migration log message says "Migrating channel messages" but this store migrates channel metadata (channels list). Consider updating it to avoid confusing logs.