Feature: Parse and add new hashtag channels from channel traffic

[recrof]

If there is previously unknown hashtag #<channel-name> mentioned in text of any other already decoded channel message, add it to the channel list.

Workflow:

• new channel message(known channel)
• decode content
• try to find channel name in the text: Hey, I created new channel called #mesh, please join
• previously unknown channel mentioned: #mesh
• add hashtag channel to the list and decode all future messages

[Kpa-clawbot]

Triage & Spec — Auto-parse hashtag channels from traffic

What already exists

1. hashChannels config — config.json accepts a list of channel names (e.g. ["#LongFast", "#test", "#sf"]). The ingestor auto-derives encryption keys via SHA256("#name")[:16] at startup. Priority: rainbow (lowest) → hashChannels-derived → explicit channelKeys (highest).

2. Ingestor channel decryption — cmd/ingestor/decoder.go decodeGrpTxt() iterates all known channel keys, computes SHA256(key)[0] to match the 1-byte channelHash in the packet, then verifies via HMAC-SHA256 MAC + AES-128-ECB decryption. If decryption succeeds and plaintext is valid UTF-8, the message is stored with channel name.

3. PR feat: add hashtag channel discovery tool #603 — Channel Discovery CLI Tool (open) — Standalone cmd/channel-discover/ binary that brute-forces channel names from a 480+ wordlist against undecrypted GRP_TXT packets in the SQLite DB. Matches by channelHash pre-filter → full MAC+decrypt verification. ~680K candidates/sec on ARM. This is an offline, manual tool — run it, get results, manually add to config.

What issue #688 asks for (and what's missing)

Issue #688 is a different approach than PR #603. Instead of brute-forcing names from a wordlist, it asks:

When a decoded channel message contains a hashtag mention like #mesh, automatically derive the key and start decrypting that channel.

This is complementary to PR #603:

• PR feat: add hashtag channel discovery tool #603: offline brute-force against unknown packets (no decoded content needed)
• Issue Feature: Parse and add new hashtag channels from channel traffic #688: online, real-time extraction from already-decoded message text

Protocol constraints

• Channel keys = SHA256("#channelname")[:16] — the # IS included
• GRP_TXT packets have a 1-byte channelHash = SHA256(key)[0] — 256 possible values, so collisions are frequent
• You cannot reverse a channelHash to a name — but if someone types #mesh in a decoded message, you can derive the key and verify it against any matching channelHash packets
• Once you have the key, you can retroactively decrypt all stored packets with that channelHash

Proposed spec

Milestone 1: Hashtag extraction from decoded messages (ingestor)

• After successfully decrypting a GRP_TXT message, scan the plaintext for #word patterns (regex: #[a-zA-Z0-9_-]{1,32})
• For each extracted hashtag not already in the known channel keys:
  • Derive the key: SHA256("#word")[:16]
  • Compute channelHash: SHA256(key)[0]
  • Attempt to decrypt ONE stored undecrypted packet with that channelHash as validation
  • If validation succeeds → add to the in-memory channel key map
• Log discovered channels: [channels] auto-discovered #mesh from message traffic

Milestone 2: Persist discovered channels

• Store discovered channel names in a discovered_channels SQLite table (name, key_hex, discovered_at, discovered_from_channel)
• Load on startup alongside config hashChannels
• Config channelKeys still takes highest priority (manual override)
• Expose via API: GET /api/channels/discovered for visibility

Milestone 3: Retroactive decryption

• When a new channel is discovered, queue re-decryption of stored undecrypted GRP_TXT packets matching that channelHash
• Update decoded_json in the DB for newly decrypted packets
• Broadcast updates via WebSocket so the UI refreshes

Milestone 4: UI indicators

• Show discovered channels in the channels list with a "discovered" badge
• For still-undecrypted channelHashes, show "Unknown channel (hash: 0xXX)" in the channels list with packet count
• Add a "discovery log" section showing when/how channels were found

Design decisions to record

1. Regex scope: Only extract #word patterns (alphanumeric + underscore + hyphen, 1-32 chars). No spaces, no special chars. This matches MeshCore's hashtag channel naming convention.
2. Validation required: Don't blindly add every #word as a channel — verify by attempting decryption of at least one packet. #the or #a in natural language shouldn't pollute the channel list.
3. No config file mutation: Don't write back to config.json. Use a separate persistence layer (SQLite table). Config remains the manual source of truth.
4. Rate limiting: Only scan for new hashtags in freshly decoded messages, not on every startup scan. Avoid re-scanning the entire DB repeatedly.
5. PR feat: add hashtag channel discovery tool #603 integration: The channel-discover CLI tool could share the same discovered_channels table, so manual brute-force results also persist without editing config.

What PR #603 covers vs what's still needed

Capability	PR #603	Issue #688
Discover channels from wordlist	✅	❌
Discover from message content	❌	✅
Runs automatically in real-time	❌ (manual CLI)	✅
Retroactive decryption	❌	✅ (M3)
Persistence of discoveries	❌ (stdout only)	✅ (M2)
UI integration	❌	✅ (M4)

Both should land — they're complementary discovery strategies.