docs(cashu): state the real goal — a user-selectable backend, not a test harness - #232
Conversation
…est harness The spec said the purpose was to "test the daemon implementation end-to-end". That is a milestone, not the goal. The goal is Cashu shipped to real users in both mostrod and this client, so a user can choose whether to trade on a node that settles over Cashu or one that settles over Lightning. Both backends are first-class and permanent. Worth correcting because the two framings disagree exactly where it is expensive to be wrong. New §1.1 spells out where, but the load-bearing ones: - The wallet holds user funds. Ecash is bearer, so a lost wallet DB is lost money and backup/restore is a release requirement, not polish. - Users never see the dev override, so detection has to work off the node's own advertisement — which promotes the upstream 38385 tags from convenience to release blocker (risk #3). - The mint is a trust assumption users did not have in Lightning mode. If the choice is theirs it has to be informed, so the mint belongs next to the node wherever one is picked, before funds move, not after (risk #9). - Web is first-class here, so "Cashu not available on web" would make the user's node choice depend on their platform. Consequently Wave 4 is renamed from "optional hardening" to "required before general availability", and C10 is split into release-blocking (backup/restore, NUT-07 reconciliation, in-flight restore, locktime countdowns) versus actual polish. Phase order and the dependency graph are untouched — what changed is which phases are optional. Also adds a release-acceptance row to the testing strategy for the paths only a real user reaches, and records early evidence that cdk does target wasm, so C9's open question is the storage backend rather than the crate.
|
Warning Review limit reached
Next review available in: 20 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
Doc-only. No code, no behaviour change.
Why
The spec said the purpose was to "test the daemon implementation end-to-end". That is a milestone, not the goal.
The goal is Cashu shipped to real users, in
mostrodand in this client, so a user can choose whether to trade on a node that settles over Cashu or one that settles over Lightning. Both backends are first-class and permanent — Cashu is not an experiment, Lightning is not being replaced.Worth correcting rather than leaving implicit, because the two framings disagree precisely where being wrong is expensive to undo.
What changes as a consequence
New §1.1 lays this out. The load-bearing differences:
Concrete edits:
Settings::get_cashu().check-wasmrecipe in its justfile,cargo check -p cdk --target wasm32-unknown-unknownin itsAGENTS.md), so the open question is the storage backend (cdk-sqliteis native-only → canWalletDatabasebe implemented over IndexedDB?) rather than the crate.Phase order and the dependency graph are untouched. What changed is which phases are optional.
Note
This branches from
mainafter #229, so it preserves C0's doc changes (the verified wire form in §2 and the resolved risk #1). An earlier draft of this change was accidentally based on a pre-C0 tree and would have reverted them — caught before pushing.