docs: add Mostro Protocol reference as critical foundation - #3
Merged
Conversation
![MostronatorCoder[bot]](https://github.githubassets.com/images/gravatars/gravatar-user-420.png){kind=avatar}
The protocol (github.com/MostroP2P/protocol) defines ALL communication between clients and mostrod. This is the source of truth for: - Message formats and actions - Order lifecycle and state machine - NIP-59 Gift Wrap encryption - Event kinds and tags Changes: - Add .specify/PROTOCOL.md with comprehensive protocol reference - Update v1-reference/README.md to highlight protocol importance - Add critical reference section to main spec.md This ensures /speckit.plan will consider protocol compliance when generating implementation tasks.
grunch
approved these changes
Mar 23, 2026
grunch
added a commit
that referenced
this pull request
Apr 2, 2026
orders.rs — Fix #7: store_trade_key_index before publish Moved store_trade_key_index(&order_id, trade_index) from before the action dispatch to inside the publish-success else branch. A publish failure no longer leaves a stale key mapping. orders.rs — Fix #5: ln_address logged in plain text Replaced ln_address={:?} (which printed the actual address) with ln_address=present/none using if ln_address_ref.is_some(). orders.rs — Fix #4: fixed 30-min deadline regardless of activity Replaced the fixed deadline with a last_activity instant that resets on each matching event. The idle timeout is now 30 minutes of inactivity, not 30 minutes of total uptime. add_lightning_invoice_screen.dart — Fix #2: Lightning Address sent with 1-sat amount _isValid now returns false for @ inputs when _resolvedSats is null. _submit also guards against it and surfaces an error instead of falling through to BigInt.one. trade_detail_screen.dart — Fix #3: OrderStatus.pending mapped to TradeStatus.active Added TradeStatus.loading to the enum and made it the default branch in _mapOrderStatus. Unresolved/initial statuses no longer match the active-trade action button sections.
4 tasks
6 tasks
grunch
added a commit
that referenced
this pull request
Jul 29, 2026
feat(orderbook): pixel-exact Order Book screen from Claude Design mock #3
codaMW
pushed a commit
to codaMW/app
that referenced
this pull request
Jul 30, 2026
…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 MostroP2P#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 MostroP2P#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.
codaMW
pushed a commit
to codaMW/app
that referenced
this pull request
Jul 30, 2026
…MostroP2P#3 Port the 'Mostro UX Redesign' mock (screen MostroP2P#3 · Order book with reasons to pick) to the Flutter home screen, matching colors, spacing, and type scale exactly: - Add OrderBookPalette to app_theme.dart with the mock's exact dark tokens (bg #0F151C, card #1A2029, elevated #222A35, green #8FE04A, gold #FFC940, etc.) plus a legibility mapping for light mode (the mock is dark-only). Scoped to this screen; AppColors untouched. - Restyle HomeScreen: 52px app bar (hamburger + bell, empty center, 1px hairline), BUY/SELL tabs with green 13px/700 active label and 2px full-width underline, rounded FILTER pill with offer count and 'Sort: best premium' caption, 16/8/90 list padding with 12px gaps. Scaffold background themed so the bottom nav matches seamlessly. - Rebuild OrderListItem card per the mock: reason pill + timestamp row, 26px/700 amount with currency/flag and 13%-alpha premium pill, 'Market price' caption, elevated reputation strip (gold star, bold numbers, dot separators), payment-method line. The mock carries no buy/sell pill (tabs scope the side); only a 'yours' pill is kept on own orders. Skeleton and empty state re-tinted to the palette. - l10n: replace orderReputationStats with reputationTradesLabel / reputationDaysLabel and add sortBestPremium (en/es/fr/de/it). - Regenerate order-list-item goldens.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds the Mostro Protocol as a critical reference for v2 development.
Why?
The protocol (https://github.com/MostroP2P/protocol) defines ALL communication between clients and mostrod. It is the source of truth for:
Changes
.specify/PROTOCOL.md- Comprehensive protocol reference including:.specify/v1-reference/README.md- Added prominent notice to read protocol firstspecs/001-mostro-p2p-client/spec.md- Added Critical Reference section at topImpact on spec-kit
When running
/speckit.plan, Claude Code will now see the protocol reference and generate implementation tasks that consider protocol compliance.