Differentiation of rumor's content elements #14
Conversation
WalkthroughThis pull request updates the JSON message formats used across the Mostro system. The changes convert multiple messages—from order cancellations and disputes to new order creation, invoice handling, order-taking, and user ratings—by replacing single JSON object formats with array structures. Each updated array includes the original order or message object along with an appended element that is either a cryptographic signature (derived via SHA256) or a null value. Additionally, some action strings and event tags have been revised without altering the underlying business logic. Changes
Possibly related PRs
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (4)
src/take_buy_range_order.md (1)
6-19: Array Structure Update for Buy Range Order Message.
The JSON message is now wrapped in an array where the first element holds the order details and the second element is a signature placeholder. Please ensure that all downstream consumers and parsers are updated to handle this new array format.src/overview.md (1)
5-16: Documentation Clarity and Grammar Refinements.
The new "## The Message" section effectively explains that all messages must now be wrapped in an array where the first element is a JSON-serialized string and the second element is its SHA256 signature. However, consider these improvements for clarity and grammar:
- Line ~7: The phrase "the sha256 hash of the serialized first element, here the structure of the first element:" could be revised to include a verb (e.g., "where the second element is the signature computed as the SHA256 hash of the serialized first element").
- Line ~13: Change "users who wants" to "users who want" to maintain subject-verb agreement.
- Line ~16: Ensure the sentence is complete by adding a missing verb.
🧰 Tools
🪛 LanguageTool
[grammar] ~7-~7: A verb may be missing.
Context: ...6 hash of the serialized first element, here the structure of the first element: - ...(THERE_MISSING_VERB)
[grammar] ~13-~13: Did you mean “want”? Alternatively, check whether the singular of ‘users’ should be used.
Context: ...tional) This field is used by users who wants to maintain reputation, it should be th...(RELATIVE_CLAUSE_AGREEMENT)
[grammar] ~16-~16: A verb may be missing.
Context: ...s field depends on theactionfield. Here an example of anew-orderorder **_me...(THERE_MISSING_VERB)
src/take_sell.md (1)
86-102: Buyer LN Invoice Submission Message
The buyer’s LN invoice submission is now encapsulated in an array. Notice the signature placeholder now sits as the second element. Also, double-check the documentation note regarding thepayment_requestarray—if the invoice includes an amount, the final array element should benullrather than a number.src/release.md (1)
136-146: Range Order – New Order Request
The JSON message for releasing a range order is still expressed as a single object. If the intention is not to change the format for range orders, this is acceptable. Otherwise, consider whether consistency with the array format is desired.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (15)
src/cancel.md(1 hunks)src/dispute.md(1 hunks)src/new_buy_order.md(2 hunks)src/new_buy_order_ln_address.md(1 hunks)src/new_sell_order.md(2 hunks)src/new_sell_range_order.md(1 hunks)src/overview.md(1 hunks)src/release.md(1 hunks)src/seller_pay_hold_invoice.md(1 hunks)src/take_buy.md(1 hunks)src/take_buy_range_order.md(1 hunks)src/take_sell.md(3 hunks)src/take_sell_ln_address.md(2 hunks)src/take_sell_range_order.md(1 hunks)src/user_rating.md(1 hunks)
🧰 Additional context used
🪛 LanguageTool
src/cancel.md
[grammar] ~21-~21: A verb may be missing.
Context: ...cel` confirming the order was canceled, here an example of rumor's content of the me...
(THERE_MISSING_VERB)
src/release.md
[grammar] ~21-~21: A verb may be missing.
Context: ...of content>" ] ``` ## Mostro response Here an example of the Mostro response to th...
(THERE_MISSING_VERB)
src/seller_pay_hold_invoice.md
[uncategorized] ~34-~34: You might be missing the article “the” here.
Context: ...sats, Mostro will send a new message to seller with the following rumor's content: ``...
(AI_EN_LECTOR_MISSING_DETERMINER_THE)
src/overview.md
[grammar] ~7-~7: A verb may be missing.
Context: ...6 hash of the serialized first element, here the structure of the first element: - ...
(THERE_MISSING_VERB)
[grammar] ~13-~13: Did you mean “want”? Alternatively, check whether the singular of ‘users’ should be used.
Context: ...tional) This field is used by users who wants to maintain reputation, it should be th...
(RELATIVE_CLAUSE_AGREEMENT)
[grammar] ~16-~16: A verb may be missing.
Context: ...s field depends on the action field. Here an example of a new-order order **_me...
(THERE_MISSING_VERB)
src/take_sell_range_order.md
[style] ~23-~23: Consider a shorter alternative to avoid wordiness.
Context: ...of content>" ] ``` ## Mostro response In order to continue the buyer needs to send a ligh...
(IN_ORDER_TO_PREMIUM)
[misspelling] ~24-~24: Use “an” instead of ‘a’ if the following word starts with a vowel sound, e.g. ‘an article’, ‘an hour’.
Context: ...tro will send back a message asking for a LN invoice indicating the correct amoun...
(EN_A_VS_AN)
src/take_sell.md
[style] ~21-~21: Consider a shorter alternative to avoid wordiness.
Context: ...of content>" ] ``` ## Mostro response In order to continue the buyer needs to send a ligh...
(IN_ORDER_TO_PREMIUM)
[misspelling] ~22-~22: Use “an” instead of ‘a’ if the following word starts with a vowel sound, e.g. ‘an article’, ‘an hour’.
Context: ...tro will send back a message asking for a LN invoice indicating the correct amoun...
(EN_A_VS_AN)
🔇 Additional comments (36)
src/user_rating.md (1)
19-32: Updated Array Format for User Rating Message.
The rating message now uses an array to encapsulate the order object and anullplaceholder. This change also updates the action from"rate"to"rate-user"and moves the user rating into the payload. Verify that client-side logic is adjusted accordingly to parse the new structure.src/overview.md (1)
20-42: New-Order Message Example Verification.
The example JSON for anew-ordermessage correctly demonstrates the updated structure and field definitions. Confirm that the serialized JSON string does not include unintended white space or line breaks as specified.src/take_sell_ln_address.md (3)
6-19: Array Structure for Lightning Address Order.
The updated buyer’s order message now wraps the order in an array with a signature placeholder. The"payment_request"field, represented as an array with anullplaceholder and a string, should be verified to ensure it meets its intended semantics.
41-51: Consistent Array Format for Mostro Response.
The Mostro response message correctly adopts the new array format. Ensure that any logic processing the response properly handles anullpayload and the appended signature placeholder.
56-84: Event Update Block Structure.
The addressable event update maintains a consistent array structure with detailed tag information. Verify that all consuming components correctly parse and utilize the provided tags and that no further adjustments are required in handling this format.src/new_sell_range_order.md (3)
6-30: New Sell Range Order Message Array Format.
The JSON structure for creating a new sell range order has been updated to an array, now including new fieldsmin_amountandmax_amountto define the order range. Confirm that setting"fiat_amount"to0properly indicates that the order is range-based.
41-63: Confirmation Message Example Consistency.
The confirmation message example remains an object format. Ensure that downstream systems are designed to handle the mix of array-based outbound messages and object-based confirmation responses consistently.
67-95: Event Publish Block Verification.
The published event block, which uses an array format with detailed tag fields (including the range values), is well-structured. Please confirm that consumers correctly interpret the range values and tag data as intended.src/new_buy_order_ln_address.md (2)
6-27: JSON Order Structure Update:
The order payload is now enclosed in an array with an appended placeholder for the index signature (SHA256 hash) of the serialized first element. This change is consistent with the broader update across the system. Please ensure that any downstream consumers are updated to expect an array rather than a single JSON object.
49-75: Confirmation Message Format Update:
The confirmation message now uses an array format with the order object as the first element and a trailingnullas the second element. This improves consistency with the new JSON format guidelines. Verify that the receiving system correctly interprets the trailingnull.src/new_sell_order.md (2)
6-30: Sell Order JSON Structure Revision:
The sell order creation JSON has been updated to an array format with the order object as the first element and anullvalue appended. This aligns with the modifications implemented for buy orders and other order-related messages.
58-81: Sell Order Confirmation Message Update:
The confirmation message for a new sell order is now formatted as an array containing the order object and anullvalue. This change maintains uniformity with the updated message formats used in other parts of the system.src/take_sell_range_order.md (2)
6-20: Range Order 'take-sell' Structure Update:
The JSON for taking a sell range order is now encapsulated in an array. The first element holds the order details, while the second element contains the index signature placeholder for the SHA256 hash. Ensure that any fee or calculation logic associated with the payload is handled appropriately downstream.
27-54: 'Add-invoice' Action Structure Update:
The 'add-invoice' JSON structure has been revised to the new array format with a trailingnull. The nested order details remain intact. Confirm that the systems processing this message treat the absence of a signature (represented bynull) as expected.src/new_buy_order.md (2)
6-28: New Buy Order Structure Update:
The new buy order payload is now wrapped in an array with a trailing field for the index signature. This update brings the buy order JSON in line with the new message format standard. Be sure to update any validations or integrations that previously expected a single JSON object.
49-75: Buy Order Confirmation Message Format:
The confirmation message for the new buy order is now an array comprising the order object followed bynull. This consistent structure should simplify processing on the receiver’s end.src/cancel.md (2)
6-16: Cancellation Request Format Update:
The cancellation request message is now structured as an array that includes the order details and an appended index signature placeholder. This change standardizes the cancellation message format with the other order-related messages.
24-35: Cancellation Confirmation Response Structure:
The Mostro response confirming cancellation has been updated to use an array format with the order object first and a trailingnullvalue. This modification ensures consistency with the updated JSON message paradigm across the system.src/dispute.md (3)
5-17: Dispute Initiation Message Format
The dispute initiation JSON has been converted from a single object to an array. The first element is the order object and the second is a placeholder for the index signature (derived via SHA256). This new structure is consistent with the overall update across the system.
23-37: Mostro Response for Seller's Dispute Initiation
The Mostro response message now uses the array format with the order object as the first element and a literalnullas the second. This aligns with the new signature requirements and offers consistency in message structure.
41-55: Dispute Message to Buyer
The message to the buyer has been similarly updated to the array format. The use ofnullas the second element is consistent with the seller response. Make sure that downstream consumers correctly interpret the absent signature here.src/take_sell.md (2)
6-18: Take-Sell Order Request Update
The JSON message for a “take-sell” order is now wrapped in an array. The first element contains the order details while the second element holds the cryptographic signature placeholder. This change is in line with the new design. Please verify that any service consuming this message is updated accordingly.
24-46: Mostro Response for Invoice Addition
The “add-invoice” response to the buyer now follows the array structure: the first element is the order object and the second element is explicitly set tonull. This is consistent with changes in other modules.src/release.md (4)
6-18: Seller Release Request Message Structure
After fiat confirmation, the seller’s release message now uses the updated array format with the additional signature element. The placeholder for the “index N signature” is present and should later be replaced by an actual SHA256 signature.
25-37: Mostro Response for Release Confirmation
The response message from Mostro to the seller is now wrapped in an array with the signature element set asnull. This change maintains consistency with other response messages.
42-53: Notification Message to Buyer for Sats Release
The message notifying the buyer of released sats has been updated to the new array format. The use ofnullas the second element remains appropriate.
151-178: New Child Order Message from Maker
The message sent by Mostro to the maker (after a child order is created) remains an object. It appears consistent with the business logic around range orders. Ensure that any downstream processing (if expecting an array format elsewhere) is aware of this exception.src/take_buy.md (5)
6-18: Take-Buy Order Request Format Update
The “take-buy” order request is now wrapped in an array; the first element is the order details and the second element is the cryptographic signature placeholder. This update aligns with the changes in other order types.
39-62: Mostro’s Response to Seller—for LN Invoice Request
(Note: This block is presented as an object and has not been changed in this diff. Confirm that the single-object format here is intentional.)
67-94: Event Update for “WaitingPayment” Status
The event update message (which changes the order status to “waiting-payment”) is provided in an array format using the “EVENT” protocol. No changes were annotated here; make sure this format is compatible with your event pipeline.
185-198: Buyer LN Invoice Submission (Repeated Instance)
The JSON message for buyer LN invoice submission is presented as an object. Verify that the system expects this format here, as other similar messages in the system have been updated to array format.
205-232: Final Active Order Event Update
The final update message that changes the status to “active” is produced in an array with the appropriate set of tags. Double-check that all tag values (such as amounts, fiat amounts, and payment methods) remain correct throughout the transition.src/seller_pay_hold_invoice.md (4)
6-32: Seller Hold Invoice Request Message Update
The message instructing the seller to pay the hold invoice is now wrapped in an array. The first element carries the order details (including the “pay-invoice” action and associated payment_request array) while the second element holds the signature placeholder. This update is well aligned with the other message-format updates.
37-63: Buyer-Took-Order Message for Post-Payment Update
After the hold invoice is paid and the buyer has sent their invoice, the “buyer-took-order” message is now expressed in the new array format. Note that fields such as"status": "active"and the inclusion of master key fields have been preserved. The signature placeholder is appended properly.
67-94: Hold-Invoice-Payment-Accepted Notification to Buyer
The message sent to the buyer notifying that the hold invoice payment was accepted is updated to the array format where the second element is now explicitly set tonull. This ensures message consistency and clarity for both parties.
168-194: Event Update for ‘Waiting-Buyer-Invoice’ Status
The updated event, which changes the order status to “waiting-buyer-invoice,” is correctly formatted as an array containing the event type and payload. All required tag fields are present.
Summary by CodeRabbit