-
Notifications
You must be signed in to change notification settings - Fork 7
docs: document maintenance mode (cant-do reason + info-event tag) #57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -121,6 +121,10 @@ This event contains specific data about a Mostro instance. The instance is ident | |
| "pow_first_contact", | ||
| "0" | ||
| ], | ||
| [ | ||
| "maintenance_mode", | ||
| "false" | ||
| ], | ||
| [ | ||
| "protocol_version", | ||
| "1" | ||
|
|
@@ -251,6 +255,14 @@ These tags advertise the node's anti-abuse-bond configuration so clients can sho | |
|
|
||
| **Disambiguation.** When `bond_enabled` is absent from the event, the daemon predates the bond feature; treat the node as not enforcing bonds. When `bond_enabled = "false"`, the daemon supports the feature but the operator has not enabled it on this instance. When `bond_enabled = "true"`, the remaining six bond tags are present and clients should expect bond messages on this node — [`pay-bond-invoice`](./pay_bond_invoice.md) for the bonded user and [`add-bond-invoice`](./add_bond_invoice.md) for the payout recipient on a slashed trade. | ||
|
|
||
| ### Maintenance mode tag | ||
|
|
||
| - `maintenance_mode`: `"true"` while the operator has put the instance in maintenance mode, otherwise `"false"`. Always emitted on daemons that support the feature; daemons that predate it omit the tag, which clients should treat as `"false"`. | ||
|
|
||
| While `maintenance_mode = "true"` the instance rejects [`new-order`](./new_sell_order.md), [`take-sell`](./take_sell.md) and [`take-buy`](./take_buy.md) with a `cant-do` whose reason is `maintenance_mode` (see [Cant Do Reasons](./message_suggestions_for_actions.md#cant-do-reasons)). Every action on an order that already exists — paying the hold invoice, `fiat-sent`, `release`, `cancel`, disputes, ratings, adding invoices — keeps working, so open trades can finish normally. The typical use is draining open escrow before the operator migrates the instance to a different Lightning node. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win 🔎 Supported by static analysis🏁 Script executed: printf '%s\n' '--- applicable repository conventions ---'
find /tmp/coderabbit-repo-knowledge/mostrop2p-protocol-20ba17c8 -maxdepth 2 -type f -name '*.md' -print
printf '%s\n' '--- convention headers ---'
head -5 /tmp/coderabbit-repo-knowledge/mostrop2p-protocol-20ba17c8/*/*.md 2>/dev/null
printf '%s\n' '--- target document context ---'
cat -n src/other_events.md | sed -n '245,275p'
printf '%s\n' '--- maintenance references ---'
rg -n -i -C 4 'maintenance_mode|maintenance mode|cant-do|new-order|take-sell|take-buy|fiat-sent|hold invoice|adding invoices' srcRepository: MostroP2P/protocol Length of output: 50376 🏁 Script executed: printf '%s\n' '--- maintenance-related definitions and contracts ---'
rg -n -i 'maintenance_mode|maintenance-mode|maintenance mode' --glob '*.md' --glob '!src/other_events.md' .
printf '%s\n' '--- status rules for the listed actions ---'
for f in src/cancel.md src/release.md src/dispute.md src/user_rating.md src/add_invoice.md src/pay_invoice.md src/fiatsent.md src/seller_pay_hold_invoice.md; do
if test -f "$f"; then
printf '\n### %s\n' "$f"
rg -n -i -C 3 'status|action|cancel|release|invoice|dispute|rating' "$f" | head -160
fi
done
printf '%s\n' '--- repository file inventory near action contracts ---'
git ls-files 'src/*' | rg '(cancel|release|invoice|dispute|rating|maintenance|other_events)'Repository: MostroP2P/protocol Length of output: 18885 🌐 Web query:
💡 Result: In the context of the MostroP2P protocol and its implementation (mostrod), the terms you mentioned relate to message handling and error management rather than a specific maintenance mode toggle feature [1][2][3]. 1. MostroP2P Messaging: new-order, take-sell, take-buy, and cant-do are core message actions defined in the Mostro protocol [4][3]. These actions allow users to interact with the orderbook [5][6]. When a Mostro node or client cannot process a request (e.g., due to invalid input, state mismatches, or system errors), it sends a cant-do message, which includes a specific reason for the failure [7][8][3]. 2. Maintenance Mode: There is no standardized "maintenance_mode" configuration parameter or global toggle within the core MostroP2P source code [1][9]. If you are encountering an issue where a node seems to be in a "maintenance mode" or is failing to process orders, this is likely not a native protocol state. 3. Technical Context: - The error cant-do is a protocol-level response used by the server to inform the client why a trade operation (like take-sell or take-buy) failed [8][3]. - If you are experiencing service disruptions, verify your node's connection to Nostr relays, its Lightning Network node (LND) status, and check the logs for specific error codes returned by the Mostro node [5][6]. - If you found the term "maintenance_mode" in relation to MostroP2P, it may be a custom modification by a specific node operator or a misunderstanding of a different system's configuration (as "maintenance_mode" is a common term in other unrelated software projects) [10][11][12][13]. To diagnose why your orders (new-order, take-sell, take-buy) are failing, examine the specific reason code provided in the cant-do message, as this will identify if the issue is related to pricing, signature validation, or state errors [7][8]. Citations:
🏁 Script executed: set -o pipefail
printf '%s\n' '--- checked-out repository identity ---'
git remote -v | head -4
printf '%s\n' '--- public daemon tree matches ---'
curl -L --fail --silent --show-error \
'https://api.github.com/repos/MostroP2P/mostro/git/trees/master?recursive=1' |
jq -r '.tree[]?.path' |
rg -i 'maintenance|action|order' | head -120
printf '%s\n' '--- public daemon source references ---'
for path in $(curl -L --fail --silent --show-error \
'https://api.github.com/repos/MostroP2P/mostro/git/trees/master?recursive=1' |
jq -r '.tree[]?.path' | rg -i '\.(rs|toml)$' | rg -i 'order|message|config|settings|lib|main' | head -80); do
body=$(curl -L --fail --silent --show-error "https://raw.githubusercontent.com/MostroP2P/mostro/master/$path" || true)
if printf '%s' "$body" | rg -qi 'maintenance_mode|maintenance-mode|maintenance mode'; then
printf '\n### %s\n' "$path"
printf '%s' "$body" | rg -n -i -C 5 'maintenance_mode|maintenance-mode|maintenance mode'
fi
doneRepository: MostroP2P/protocol Length of output: 494 Limit the maintenance guarantee to actions allowed by the order status. The protocol defines 🤖 Prompt for AI Agents |
||
|
|
||
| Clients SHOULD read this tag and warn the user before they compose or take an order on an instance in maintenance mode, rather than letting the user mine proof of work for a request that will be rejected. The tag flips back to `"false"` when the operator re-opens the instance; the info event is republished immediately on each change and then at the usual interval. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift 🔎 Supported by static analysis🏁 Script executed: printf '%s\n' '--- applicable convention and learning files ---'
find /tmp/coderabbit-repo-knowledge/mostrop2p-protocol-20ba17c8 -maxdepth 2 -type f \( -path '*/mostrop2p-protocol*' -o -path '*/learnings/*' -o -path '*/architecture/*' \) -print 2>/dev/null | sort
printf '%s\n' '--- changed hunk ---'
git diff -- src/other_events.md
printf '%s\n' '--- target context ---'
sed -n '235,280p' src/other_events.mdRepository: MostroP2P/protocol Length of output: 4944 🏁 Script executed: printf '%s\n' '--- repository conventions ---'
cat /tmp/coderabbit-repo-knowledge/mostrop2p-protocol-20ba17c8/learnings/src.md
cat /tmp/coderabbit-repo-knowledge/mostrop2p-protocol-20ba17c8/learnings/repo-wide.md
printf '%s\n' '--- maintenance and status-event references ---'
rg -n -S -C 3 'maintenance_mode|38385|status event|status-event|interval' --glob '!src/other_events.md' .Repository: MostroP2P/protocol Length of output: 9828 🌐 Web query:
💡 Result: In the context of the MostroP2P project, the term "maintenance_mode" is not a standard configuration property or feature of the Mostro daemon itself. Instead, the Mostro daemon utilizes Nostr NIP-33 replaceable events for managing its metadata and status, specifically through the "Mostro info" event [1][2][3]. The Mostro info event is identified by Nostr event kind 38385 [1][4][2]. This event is used by the daemon to advertise instance-specific metadata, such as version information, fee structures, fiat currencies accepted, and LND node details [4][2]. Because it is a NIP-33 replaceable event, any updates to the configuration or metadata are published by the daemon as a new kind 38385 event, which replaces the previous one on the relay [2][3]. Your query regarding "maintenance_mode" and "republished immediately interval" does not correspond to documented functionality within the official MostroP2P codebase or its NIP-33 event specifications [1][5][2]. It is possible these terms originate from a different system, such as Proxmox Backup Server (which explicitly implements a Citations:
🌐 Web query:
💡 Result: Maintenance mode is a specialized state in software applications and systems designed to suspend normal operations, allowing administrators to perform critical tasks—such as updates, migrations, configuration changes, or repairs—without risking data corruption or inconsistent states [1][2][3]. In technical environments, maintenance mode typically serves the following purposes: - Data Protection: Preventing users from modifying data or triggering background processes while critical system changes are underway [3]. - Service Stability: Redirecting traffic or displaying a user-friendly notification to inform stakeholders that the service is temporarily unavailable, rather than allowing them to encounter unpredictable errors [4][2]. - Administrative Access: Restricting system access to authorized personnel only, often enabling privileged interfaces or diagnostic tools that are disabled during standard operation [4][5]. The implementation of maintenance mode varies significantly by architecture: - Web Applications: Often involves placing a static "Maintenance" page in front of the application server (e.g., via a reverse proxy like Nginx or a load balancer) to ensure users receive a clear message during downtime. - Backend Services & Daemons: May involve shutting down specific event loops, background schedulers, or API interfaces (like gRPC) through configuration toggles or command-line flags to prevent new activity [6][4][2]. - Databases: May require setting the database to read-only mode to prevent write operations while backups are performed or schema migrations are applied [5][7][3]. Best practices for maintenance mode include providing clear communication to users about the duration and purpose of the downtime, ensuring the transition into and out of maintenance mode is automated and atomic to minimize the window of unavailability, and verifying the integrity of the system before resuming normal service [8][2][9]. Citations:
🏁 Script executed: python3 - <<'PY'
import json, urllib.request
base = "https://api.github.com/repos/MostroP2P/mostro"
for endpoint in ("/git/trees/main?recursive=1",):
req = urllib.request.Request(base + endpoint, headers={"Accept": "application/vnd.github+json", "User-Agent": "review-inspection"})
with urllib.request.urlopen(req, timeout=20) as r:
data = json.load(r)
for item in data.get("tree", []):
path = item.get("path", "")
if any(term in path.lower() for term in ("info", "config", "maint", "event")):
print(path)
PYRepository: MostroP2P/protocol Length of output: 2442 🌐 Web query:
💡 Result: In the context of the Mostro P2P protocol, 38385 is the Nostr event kind defined as Citations:
🏁 Script executed: curl -ksS -H 'Accept: application/vnd.github+json' -H 'User-Agent: review-inspection' \
'https://api.github.com/repos/MostroP2P/mostro/git/trees/main?recursive=1' |
jq -r '.tree[]?.path' |
grep -Ei '(^|/)(src|docs|config|event|info|main|mostro).*|maint'Repository: MostroP2P/protocol Length of output: 2654 🏁 Script executed: for p in src/app.rs src/nip33.rs src/config/settings.rs src/config/types.rs src/config/mod.rs src/rpc/service.rs src/rpc/server.rs src/main.rs src/scheduler.rs; do
echo "--- $p ---"
curl -ksS "https://raw.githubusercontent.com/MostroP2P/mostro/main/$p" |
grep -n -E -C 5 'maintenance|38385|NOSTR_INFO|info_event|interval|publish' || true
doneRepository: MostroP2P/protocol Length of output: 50376 🏁 Script executed: for p in src/nip33.rs src/scheduler.rs src/config/types.rs; do
echo "--- $p ---"
curl -ksS "https://raw.githubusercontent.com/MostroP2P/mostro/main/$p" |
sed -n '1,30p;430,540p;560,730p;185,225p' 2>/dev/null
done
printf '%s\n' '--- exact maintenance references in all current Rust sources ---'
curl -ksS 'https://api.github.com/repos/MostroP2P/mostro/git/trees/main?recursive=1' |
jq -r '.tree[]?.path | select(test("^src/.*\\.rs$"))' |
while read -r p; do
body=$(curl -ksS "https://raw.githubusercontent.com/MostroP2P/mostro/main/$p")
if printf '%s' "$body" | grep -qi 'maintenance'; then
echo "$p"
printf '%s' "$body" | grep -in -C 3 'maintenance'
fi
doneRepository: MostroP2P/protocol Length of output: 47763 Align this contract with the daemon. 🤖 Prompt for AI Agents |
||
|
|
||
| ## Information about the Relays Where Events Are Published | ||
|
|
||
| The operator of a Mostro instance decides which relays the events from that instance are published to. This information can be accessed in events [kind 10002](https://github.com/nostr-protocol/nips/blob/master/65.md), which are published by the Mostro instances. | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Clients that copy this reason-to-message mapping will look for
maintenance-mode, but the newly added serialization note and the rejection description inother_events.mdboth specify the actual wire value asmaintenance_mode. As a result, maintenance-mode rejections will miss this entry and fall through to generic handling; label the reason with the underscore form.Useful? React with 👍 / 👎.