Foundation for messages too large for a single transaction (tier 2's 16-output
ceiling, ~4000 chars). A long message is now split across SEVERAL transactions
that share a random message id; each carries a slice of the one ciphertext with
GLOBAL chunk indices, and the receiver reassembles across the siblings.
Protocol: the Message header gains an optional "mid" (message id); "n" is reused
as the TOTAL chunk count and its bound raised to kHushChatMaxMessageChunks (64 ⇒
up to ~16 KB / 4 txs, tunable, ≤256 for the 2-hex index). The grouper, when a
tx's header carries "mid", emits a PARTIAL (its global-indexed chunks + message
id + total) instead of reassembling in-place; HushChatTransactionMetadata
carries those partials through. Crypto is untouched — one secretstream session
for the whole message, chunking is transport-only.
Compose: splitOutgoingMessage() returns one OutgoingChatMemos per transaction
(one element = the classic tier-1/2 single tx, byte-identical; several = tier 3).
buildOutgoingMessage (single-tx) is unchanged. Old clients bound "n" to 16 so a
tier-3 header fails to parse and its memos are dropped — graceful degradation.
Unit-tested (testHushChatLargeMessageTier3): a ~9000-char message splits into 3
txs, every output shuffled, slices gathered across siblings, reassembled and
decrypted back to the original; short message stays single-tx (no mid); the
total-chunk cap is enforced. The stateful accumulator (persisted, confirm-gated),
sequential broadcast, and progressive/incomplete UI follow in later commits.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
A message whose ciphertext exceeds one 512-byte memo is now split across up to
kHushChatMaxMessageParts (16) payload outputs in a SINGLE transaction, lifting
the ~239-byte cap to a few KB while staying atomic, instant (0-conf), and
one-fee. The crypto is untouched (one secretstream push/pull); chunking is a
transport concern:
- Header gains an optional part count `n` (emitted only when >1, so a 1-part
message stays byte-identical on the wire); bounded in the parser.
- Each chunk is a 2-hex part-index prefix + its ciphertext slice, so the
receiver reorders them after the daemon's output shuffle.
- OutgoingChatMemos carries a payload vector; chatSendOutputs emits header + N
payloads (both broadcast call sites already iterate the result).
- The grouper gains a multi-part pre-scan: a lone Message header with n>1 →
collect the N indexed chunks, sort, strip, concat → one pair; anything else
falls through to the classic single-pair path (older clients mis-pair and
drop — graceful). A body beyond the cap is refused as TooLong (tier 3 later).
Round-trip (shuffled outputs), 1-part byte-identical, and cap all unit-tested.
Larger-messages tier 2; tier 3 (multi-tx) + the denser raw-memo encoding remain.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Introduces HushChatHeaderType::Control — a self-addressed control signal
(delete / restore / mark-sensitive) that rides a chat tx as a header memo
carrying an `op`, paired with a plaintext label payload so it groups like a
normal header/payload pair. The op VALUE is not restricted at parse time so a
future op reaches newer clients and is ignored by older ones; unknown header
types still fail-closed (grouped as an invalid header, never surfaced, never a
crash), preserving forward-compat.
Foundation for the on-chain chat delete/restore feature (Phase A).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Carry the sender's compose time as an optional "ts" (Unix seconds) in the
plaintext header JSON that rides outside the AEAD, and prefer it as the
displayed message time so both ends show the same send time regardless of when
the tx confirms. Parse "ts" leniently. On ingest, clamp: reject a "ts"
implausibly in the future vs the receive/block time (1h skew tolerated) so a
wrong/ahead peer clock can't pin messages to the bottom of a thread; a past
compose time is fine (the note buffer may broadcast a queued message later, and
a confirmed tx's block time is always >= compose time). Tests cover the
round-trip and the future-clock clamp.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Phase 1 Step 1 (the linchpin). The receive path had nothing to decrypt:
HushChatTransactionMetadata carried only payload_position/size, and the
extractor discarded the paired payload memo + the header's "e"/"p". Widen the
metadata with sender_public_key_hex ("p"), secretstream_header_hex ("e"), and
payload_memo (ciphertext hex for a Message; request text for a ContactRequest),
populated from the already-parsed header/payload pair.
Add an end-to-end receive-path test: derive two identities, encrypt Alice->Bob,
wrap it as a HushChat header+payload memo pair, run it through
extractHushChatTransactionMetadata, and decrypt straight from the carried
metadata. Also asserts the harvest yields nothing when the feature is disabled.
Fields are only populated when featureEnabled (the extractor already returns
early otherwise), so an OFF build produces no decrypt material.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Two dead-code removals surfaced by the audit; no runtime behavior change.
1. Delete the lite-lifecycle "readiness" scaffold (~1,586 lines). The pure
dry-run evaluateLiteWalletServerLifecycleReadiness (whose own status text
says "wallet lifecycle execution is still disabled in this scaffold") had
zero callers; executeLiteWalletServerSelectionUi had zero callers; and
executeLiteWalletLifecycleUiRequest's only caller was a fallback in
settings_page reached only when app->liteWallet() is null. Deleted
lite_wallet_server_lifecycle_readiness.{h,cpp} and the readiness /
UI-execution machinery + enums + translation tables from both adapters,
keeping the genuinely-live helpers (liteConnectionSettingsFromAppSettings,
applyLiteConnectionSettingsToAppSettings, redactLiteServerSelectionValue,
and the LiteWalletLifecycleUiExecutionInput DTO the live create/open/
restore path still uses). The null-backend fallback now sets a plain
"Lite wallet backend unavailable" status. This is exactly the
readiness/scaffold pattern CLAUDE.md forbids regrowing.
2. Split the HushChat fixture/capture-manifest/seed-projection tooling
(~2,050 lines, incl. the libsodium seed-projection) out of
chat_protocol.cpp (1854 -> 284) and chat_protocol.h (586 -> 105) into a
new chat_fixture_tooling.{h,cpp} compiled ONLY into the HushChatFixtureCheck
dev tool — never into the app, lite, or test binaries (verified via nm).
The app keeps only the runtime slice (memo parsing + tx metadata
extraction) that network_refresh_service actually calls. Also moved the
decrypt-preflight/hex helpers, which likewise had no runtime caller.
Note: the HushChat split is on gated-off experimental code and should be
coordinated with the pending dormant-HushChat-content handling (commit
af06b8b) before the lite PR — done here as a pure mechanical split, no redesign.
Full-node + Lite + HushChatFixtureCheck build clean; ctest 1/1; hygiene clean.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Preserve the previously-uncommitted lite wallet implementation and related dev WIP
under version control:
- src/wallet/ lite services: client bridge, bridge runtime, connection, lifecycle,
sync, gateway, result parsers, state mapper, artifact contract/resolver, refresh
services, UI adapters, wallet_backend/capabilities. (Includes two small M1 fixes:
lifecycle walletReady now parses the response; default chain name -> "main".)
- src/chat/ chat protocol; tests/fixtures/ (lite + hushchat); tools/hushchat_fixture_check.cpp;
scripts/build-lite-backend-artifact.sh.
- Pre-existing modified app_network/security/wizard, network_refresh_service, sidebar,
mining_tab, bootstrap dialog, and version headers captured as-is.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
DanSandClaude Opus 4.8