Analytics → Channels: default "Public" channel (0x11) shown as opaque "Encrypted (0x11)" despite known/configured key

[syssi]

Summary

On /#/analytics?tab=channels (e.g. https://corescope.meshrheinland.de/#/analytics?tab=channels) the Public channel shows up as an opaque row Encrypted (0x11) in the Encrypted section at the bottom of the list — even though it carries the most messages and senders.

Channel hash 0x11 is the firmware-default MeshCore Public channel. Its key is well-known and is in fact shipped built-in:

// cmd/ingestor/main.go:1300
func builtinChannelKeys() map[string]string {
    ...
    "Public": "8b3387e9c5cdea6ac9e5edbaa115cd72",
}

It can additionally be set explicitly in config:

"channelKeys": {
  "Public": "8b3387e9c5cdea6ac9e5edbaa115cd72"
}

…but that key is not applied on this view — the row stays opaque and sorts to the bottom.

Expected

The 0x11 Public channel should be treated as a known / decrypted channel: rendered with its real name "Public" and grouped at the top of the list (My Channels / Network), consistent with every other channel whose key is known.

Actual

Rendered as Encrypted (0x11), encrypted: true, bucketed into the Encrypted group, sorted to the bottom — despite the key being configured/built-in.

Root cause (pointers)

The encrypted-channels aggregation counts only GRP_TXT packets whose decryption status is no_key, and hard-labels them, ignoring known keys:

// cmd/server/store.go:5093  GetEncryptedChannels()
if decoded.Type != "GRP_TXT" || decoded.DecryptionStatus != "no_key" { continue }
...
"hash":      "enc_" + ch.hash,
"name":      "Encrypted (0x" + ch.hash + ")",
"encrypted": true,

Client-side de-opaquing in decorateAnalyticsChannels (public/analytics.js:976) only resolves a hash → name via browser-local keys (buildHashKeyMap() → ChannelDecrypt.getStoredKeys(), public/analytics.js:1015). The server-side configured / built-in channelKeys (incl. Public) are never consulted on this view, so 0x11 never gets a name or the decrypted grouping.

Note the decoder does know how to decrypt Public (cmd/ingestor/decoder.go:544 decodeGrpTxt emits Channel: "Public", DecryptionStatus: "decrypted" when a key matches) — so the gap is specifically the analytics-channels aggregation/labeling path, not the crypto.

Suggested fix

Reconcile the encrypted-channels listing with known channel keys (server-side built-in + configured channelKeys), so a hash that maps to a known key (e.g. 0x11 → Public) is emitted with its real name and encrypted: false / a non-opaque group, instead of Encrypted (0x11). Alternatively, surface the server's configured/built-in key hashes to the client so decorateAnalyticsChannels can de-opaque them like browser-stored keys.

Environment

• View: /#/analytics?tab=channels
• Reproduced on: https://corescope.meshrheinland.de/#/analytics?tab=channels

[Kpa-clawbot]

Severity: P2 — visible UX/data-quality regression on Analytics→Channels; Public channel mislabeled & demoted on every deployment that uses the default key.

Claim: confirmed.

Code today:

• cmd/server/store.go:5093 GetEncryptedChannels() filters DecryptionStatus == "no_key" only and hard-emits name = "Encrypted (0x"+hash+")", encrypted: true — never consults channelKeys (built-in or configured).
• cmd/server/db.go:1638 mirror impl: same shape, also no key lookup.
• cmd/ingestor/decoder.go:544 proves decoder DOES know Public (8b3387e9c5cdea6ac9e5edbaa115cd72) and emits Channel:"Public", DecryptionStatus:"decrypted" when key matches — so the gap is purely the encrypted-listing aggregator on the server, plus the client-side decorateAnalyticsChannels (public/analytics.js:976) that only knows browser-local keys.

Findings:

• (carmack): Single source of truth violation — builtinChannelKeys() lives in ingestor; encrypted-channel aggregator in server doesn't import it. Hot path is cheap (15s cache), fix is a hash→name precompute, ~zero cost.
• (kent-beck): TDD-friendly — encrypted_channels_test.go:30 already exists; add a case asserting 0x11 with built-in Public key resolves to a decrypted-bucket row, not Encrypted (0x11).

Fix path: Two coupled changes:

1. cmd/server/store.go:5093 + cmd/server/db.go:1638 — accept a knownHashes map[byte]string (precomputed from builtinChannelKeys() ∪ config channelKeys); when hash matches, emit name=<real>, encrypted:false, drop the enc_ prefix. Plumb through routes.go:2549,2562.
2. Optionally surface /api/channels/known-hashes so decorateAnalyticsChannels can de-opaque hashes the browser doesn't have stored locally (separate small PR).

Effort: M (2 server funcs + route plumb + 1 test file). Step 2 is S but design-coupled.

Dup check: searched "encrypted channel public 0x11 known key" + GetEncryptedChannels history — no prior issue/PR; #1648/#1657 only touched client-side opaque rendering.

Triage verdict: needs-operator-input — confirm whether to (a) fix server-side only (collapses to "Public" everywhere immediately, breaks any operator who deliberately removed Public from config to hide it) or (b) also expose /api/channels/known-hashes for client merging. Either is small; pick one before spawning impl.