Taker info message to maker. I think that could be modifies in a more generic UserInfo. #473
Conversation
WalkthroughThis pull request contains several code adjustments. Minor formatting is fixed in Changes
Sequence Diagram(s)sequenceDiagram
participant Caller as Invoice/Flow Handler
participant Notifier as notify_taker_reputation
participant DB as Database Pool
participant Queue as Message Enqueuer
Caller->>Notifier: Call notify_taker_reputation(pool, order)
Notifier->>DB: Query user's reputation info
DB-->>Notifier: Return reputation data (rating, reviews, operating days)
Notifier->>Queue: Enqueue message with reputation details
Queue-->>Notifier: Acknowledge message queued
Possibly related PRs
Suggested reviewers
Poem
Tip ⚡💬 Agentic Chat (Pro Plan, General Availability)
📜 Recent review detailsConfiguration used: CodeRabbit UI ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
🪧 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 (
|
Catrya
left a comment
There was a problem hiding this comment.
@arkanoider mostro is sending the identity key. But it shouldn't send any keys, not even the trade key.
The counterparty's trade key should only be sent when it goes into Active status.
And the reputation data was not sent.
Mostro sent you this message for order id: 117353b2-75ca-497e-8a1b-6c19f41a59b8 at 2025-04-03 22:29:06 UTC
Action: TakeSell
Payload: Some(
Peer(
Peer {
pubkey: "ad2c3e3f80ff1bf7630f6c42dd3a4f5aa6f5d6eb0c0f817a65d6023b412d89d0",
},
),
)
Mostro sent you this message for order id: 117353b2-75ca-497e-8a1b-6c19f41a59b8 at 2025-04-03 22:29:48 UTC
Pay this invoice to continue --> lnbcrt5u1pn77z7upp5e8scynwc69u3pm2x3sgq0wtmrcv9e58wsg9ty930wv7tnay9mgcsdf5g4ekxun0wusxzmt0w4h8ggz0wfjx2u3qyvcnzdenx5ekyv3dxu6kxcfdxsunwefd8psnzc3dxe3nzwtxxsckzdfevgur5gzng4xycgzz23pjqen0wgsyx42syqmzqtfqf96zq46ff3xzq3jjg4z453fqf98zq46pf3xy24pwypyhggrhd9kxcgrjv4kx2ctnv5sx7mnrv5s8jmm4ypex2mr9v9ek2t3qf96zqamfd3kzqun9w36hym3qd9nzqcn409jhygrydajhxgrwda6zqcm0denxjundyp6xsefqwpshjmt9de6qcqzysxqyz5vqsp55t68ps2fduuukyn62sgddwe08ecs4xmqhxpdy8590xzpekekrycs9qyyssql3hqedh7h4tdz93au4qpy33z4z930gcdf5js0un5vec6rk6762vpkhkzxquct2a7f7v9tuqwzaxvarj3l0rc9xras4stc6vucrxs45qplhzk93
Bye Bye!
Hi Catrya! Got your point, i used id key for error but i admit i wanted to use. trade key in my mind. I think it's not a problem to remove also the key info in the message, in case i can just leave an empty string to start. I think that in the cli you need tha patch part in cargo. toml to get user data, i saw them on my local tests. Will fix this morning. |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (3)
src/util.rs (3)
976-978: Consider adding a comment explaining the empty pubkeyThe empty string for the pubkey field is a good privacy practice as mentioned in the PR description, but it would be helpful to add a comment explaining this design decision for future maintainers.
Some(Payload::Peer(Peer { + // Using empty string for pubkey to protect user privacy pubkey: "".to_string(), reputation: Some(reputation_data), })),
956-971: Consider logging when user reputation data isn't foundWhen user information isn't found in the database, the function silently creates default reputation data. Consider adding a log entry to help with debugging these cases.
let reputation_data = match is_user_present(pool, event.sender.to_string()).await { Ok(user) => { let now = Timestamp::now().as_u64(); UserDisputeInfo { rating: user.total_rating, reviews: user.total_reviews, operating_days: (now - user.created_at as u64) / 86400, } } - Err(_) => UserDisputeInfo { + Err(e) => { + info!("User data not found for sender {}: {}", event.sender.to_string(), e); + UserDisputeInfo { rating: 0.0, reviews: 0, operating_days: 0, - }, + } + }, };
949-955: Add documentation for the functionThe purpose and behavior of this function should be documented with rustdoc-style comments, explaining the parameters and describing what the function does.
+/// Notifies the destination about the taker's reputation +/// +/// This function retrieves the sender's reputation data (if available) and sends it to the +/// destination. If the sender isn't found in the database, default values (zeros) are used. +/// For privacy protection, the actual pubkey is not included in the message. +/// +/// # Arguments +/// * `pool` - Database connection pool +/// * `destination_pubkey` - Public key of the message recipient (typically the maker) +/// * `event` - The event containing sender information +/// * `request_id` - Optional ID to track the request +/// * `order` - The order being taken pub async fn notify_taker_reputation( pool: &Pool<Sqlite>, destination_pubkey: PublicKey, event: &UnwrappedGift, request_id: Option<u64>, order: &Order, ) -> Result<(), MostroError> {
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (6)
Cargo.toml(1 hunks)src/app/admin_take_dispute.rs(1 hunks)src/app/fiat_sent.rs(2 hunks)src/app/take_buy.rs(2 hunks)src/app/take_sell.rs(2 hunks)src/util.rs(2 hunks)
🧰 Additional context used
🧬 Code Definitions (2)
src/app/take_sell.rs (1)
src/util.rs (1)
notify_taker_reputation(949-985)
src/util.rs (1)
src/db.rs (1)
is_user_present(404-419)
🔇 Additional comments (9)
Cargo.toml (1)
51-51: Minor formatting change noted.The removal of the trailing newline is a non-functional formatting change.
src/app/take_buy.rs (2)
1-4: LGTM!The import statement correctly adds the new
notify_taker_reputationfunction.
91-93: Good implementation of the taker reputation notification.The function is correctly placed after updating the user trade index and before showing the hold invoice, maintaining proper flow control.
src/app/take_sell.rs (2)
1-4: LGTM!The import statement correctly includes the new
notify_taker_reputationfunction.
119-121: Good implementation of the taker reputation notification.This mirrors the implementation in take_buy.rs, maintaining consistency across both action types.
src/app/fiat_sent.rs (2)
56-59: Improved Peer initialization with explicit fields.The change from constructor method to explicit struct initialization improves code clarity by making field assignments visible.
72-75: Consistent Peer initialization pattern.This change follows the same pattern as the previous Peer initialization, maintaining consistency.
src/util.rs (2)
949-985: Good implementation of taker reputation notificationThis function properly retrieves user reputation data and sends it to the order maker with privacy protection (using empty string instead of actual pubkeys). The calculation of operating days using seconds-to-days conversion (dividing by 86400) is correct.
972-982:Details
❓ Verification inconclusive
Verify that Action::TakeSell is appropriate for all cases
The function is using
Action::TakeSellwhich might not be appropriate if this function is called from contexts other than when a sell order is taken.
🏁 Script executed:
#!/bin/bash # Find where notify_taker_reputation is called to verify action context # Search for calls to the function rg -A 3 -B 3 "notify_taker_reputation" --type rustLength of output: 1759
Action Type Usage Verification
The code in
src/util.rs(lines 972–982) unconditionally usesAction::TakeSellwhen enqueuing the order message. However, our search shows thatnotify_taker_reputationis invoked from bothsrc/app/take_sell.rs(selling flow) andsrc/app/take_buy.rs(buying flow). Please verify that usingAction::TakeSellis appropriate for both contexts. If the intent is to distinguish between sell and buy actions, consider conditionally setting the action (for example, using a different enum variant likeAction::TakeBuyin the buying flow).
|
@Catrya , now pubkey in new Peer message is set to empty string to avoid sending more infos to taker. [dependencies]
mostro-core = "0.6.36"
[patch.crates.io]
mostro-core = { path = "../catrya/mostro-core" } |
|
Hi @Catrya , after tg discussion we had yesterday, now i modified the message in the way described below.
after taker adds invoice to the order the maker receives this message below: Action: PayInvoice
Payload: Some(
Peer(
Peer {
pubkey: "",
reputation: Some(
UserDisputeInfo {
rating: 0.0,
reviews: 0,
operating_days: 0,
},
),
},
),
)In the Action: AddInvoice
Payload: Some(
Peer(
Peer {
pubkey: "",
reputation: Some(
UserDisputeInfo {
rating: 0.0,
reviews: 0,
operating_days: 0,
},
),
},
),
)Let me know if I got completely your idea @Catrya . |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
src/util.rs (1)
949-1021: Well-structured implementation of taker reputation notification.This function successfully implements the core logic for notifying makers about taker reputation, addressing the requirements outlined in the PR. Key aspects:
- Correctly distinguishes between buy and sell order flows
- Properly retrieves reputation data (rating, reviews, operating days) when available
- Falls back to zeros for new or privacy-focused users
- Sets the
pubkeyfield to an empty string as requested in the PR comments- Uses appropriate error handling for invalid states
The implementation follows the design discussed in the PR comments and integrates well with the existing messaging architecture.
One minor suggestion: consider adding a documentation comment that explains the purpose and behavior of this function, especially detailing when zeros are returned for reputation data.
+/// Sends a notification message to the maker with information about the taker's reputation. +/// +/// This function retrieves the taker's reputation data (rating, reviews, and operating days) +/// and sends it to the maker. If the taker is new or has privacy settings enabled, +/// all reputation fields are set to zero. The function determines the appropriate +/// taker and maker based on the order type and status. +/// +/// # Arguments +/// +/// * `pool` - Database connection pool +/// * `order` - The order being processed +/// +/// # Returns +/// +/// A Result indicating success or an error with the reason pub async fn notify_taker_reputation( pool: &Pool<Sqlite>, order: &Order, ) -> Result<(), MostroError> {
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
src/app/add_invoice.rs(2 hunks)src/flow.rs(2 hunks)src/util.rs(2 hunks)
🧰 Additional context used
🧬 Code Definitions (1)
src/flow.rs (1)
src/util.rs (2)
enqueue_order_msg(837-854)notify_taker_reputation(949-1021)
🔇 Additional comments (6)
src/app/add_invoice.rs (2)
2-3: Updated imports to include the new reputation notification functionality.The import list now includes the
notify_taker_reputationfunction from theutilmodule, which aligns with the new feature implementation for notifying makers about taker's reputation.
70-74: Successfully implemented reputation notification for buyers who take sell orders.This code correctly notifies the maker (seller) about the taker's (buyer's) reputation when the buyer adds an invoice to a sell order. The implementation follows good practices by:
- Adding clear logging with
tracing::info!- Properly propagating errors with the
?operator- Executing at the appropriate point in the workflow, after order validation but before further processing
This implementation aligns with the PR objective of providing makers with information about the takers.
src/flow.rs (2)
1-1: Updated imports to include the new reputation notification functionality.The import list now includes the
notify_taker_reputationfunction from theutilmodule, which is used later in the code to notify makers about taker's reputation.
108-112: Successfully implemented reputation notification for sellers who take buy orders.This code correctly notifies the maker (buyer) about the taker's (seller's) reputation when a hold invoice is paid. The implementation:
- Is strategically placed in the workflow - only executing when the order doesn't have a buyer invoice yet
- Follows the same pattern as in the add_invoice.rs file with proper logging and error handling
- Completes the notification feature for both sides of the transaction flow
This implementation ensures that reputation information is communicated to makers regardless of whether they're selling or buying.
src/util.rs (2)
18-18: Added import for UserDisputeInfo struct.Added the necessary import for the
UserDisputeInfostruct from the dispute module, which is used to structure reputation data in the new notification feature.
22-22: Added import for Peer struct.Added the necessary import for the
Peerstruct from the message module, which is used to encapsulate the reputation data when sending notifications.
why call this UserDisputeInfo? it's not "for dispute", it is for the user to know the reputation of the counterpart, can we change this? |
Damn right! Will. fix asap... |
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/util.rs(2 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (1)
src/util.rs (1)
src/db.rs (1)
is_user_present(404-419)
🔇 Additional comments (2)
src/util.rs (2)
18-18: New import ofUserInfolooks appropriate.No issues identified; importing
UserInfois consistent with the new functionality.
22-22: Import ofPeerappears correct.This import aligns with the added usage in the new function.
|
OK now makers will receive this message: Action: PayInvoice
Payload: Some(
Peer(
Peer {
pubkey: "",
reputation: Some(
UserInfo {
rating: 0.0,
reviews: 0,
operating_days: 0,
},
),
},
),
)And admin will receive this when he takes a dispute: Dispute info: Some(
SolverDisputeInfo {
id: 88fd05e7-cbed-4c62-bbaf-d9f12a5de927,
kind: "sell",
status: "dispute",
hash: Some(
"0d96c33e9419a56fab701ec4d9c44e83913f1c24e6697be12975c4056b0b94bf",
),
preimage: Some(
"556985d89c32e6099cc0072fe7a0987dfb6cfea59dfcbd4ba0b4ba633b631af1",
),
order_previous_status: "active",
initiator_pubkey: "53e7a7efd12c11893a78ace22bef4f3bdbf0784176e32b39520fe58413f3ac3b",
buyer_pubkey: Some(
"53e7a7efd12c11893a78ace22bef4f3bdbf0784176e32b39520fe58413f3ac3b",
),
buyer_token: Some(
860,
),
seller_pubkey: Some(
"ebe5e892904fec95e645e211c0115e1e219b3d0ddb0b33e296483cfdab378d3e",
),
seller_token: Some(
236,
),
initiator_full_privacy: false,
counterpart_full_privacy: false,
initiator_info: Some(
UserInfo {
rating: 0.0,
reviews: 0,
operating_days: 0,
},
),
counterpart_info: Some(
UserInfo {
rating: 0.0,
reviews: 0,
operating_days: 0,
},
),
premium: 0,
payment_method: "sepa",
amount: 19026,
fiat_amount: 14,
fee: 0,
routing_fee: 0,
buyer_invoice: Some(
"lnbcrt190260n1pnl5yj5sp557qq5mxvq5ccn7drkqccag8pezl4dzyh3wh5k224t2fx7drc5ngspp5dj5fyt3hhyn3099pjc9d3pdz2t0yh869vekyzp2td004hr2ru7hqdp92phkcctjypykuan0d93k2grxdaezqcmpwfhkcxqyjw5qcqp2rzjq09tcxqtamfsl5mz0yd7gdaraj6uzg685vq9wmr4l86uwyngv62ukqqqssqqqqgqqqqqqqqpqqqqqzsqqc9qxpqysgqkwywts7ygdvzm82uujmcn9rsxv0yj8j8eq7e4wnrknans9ssptsjjd355n5h3lrvrv78ara59h5czmyn7ds9ejfxmwayeahwrvzh2gcpx7hsxv",
),
invoice_held_at: 1744442143,
taken_at: 1744441922,
created_at: 1744441890,
},
)
As usual this is related to a mostro-core pull request related to the new name struct. |
Catrya
left a comment
There was a problem hiding this comment.
Hi @arkanoider
It's weird that when the message to the maker appears, everything is set to 0, including reputation, days etc but it's incorrect because the maker didn't use privacy mode.
When a dispute is opened, in the message to the admin the data appears correctly.
Mostro sent you this message for order id: 7f0e8c13-448b-49d7-b3ac-fb4e50351b5a at 2025-04-15 16:38:35 UTC
Action: PayInvoice
Payload: Some(
Peer(
Peer {
pubkey: "",
reputation: Some(
UserInfo {
rating: 0.0,
reviews: 0,
operating_days: 0,
},
),
},
),
)
in dispute:
Mostro sent you this message for order id: 485c97c0-d0db-4127-a83a-ca07e1e26aec at 2025-04-15 16:42:36 UTC
Action: AdminTookDispute
Dispute id: 485c97c0-d0db-4127-a83a-ca07e1e26aec
Dispute info: Some(
SolverDisputeInfo {
id: 7f0e8c13-448b-49d7-b3ac-fb4e50351b5a,
kind: "sell",
status: "dispute",
hash: Some(
"6a1da4d152b123bc5f38fd5b7e8ed8db455fa384c111dd640cf6eb0b36f182a1",
),
preimage: Some(
"1a33d83cee895ed0d77a2b412a364925ea94e995cd127110f0300cfabe331798",
),
order_previous_status: "active",
initiator_pubkey: "10a005713577b8b27fb7fbc4c32142a355e5f34db67b8c352b058aed7f9a7afa",
buyer_pubkey: Some(
"10a005713577b8b27fb7fbc4c32142a355e5f34db67b8c352b058aed7f9a7afa",
),
buyer_token: Some(
907,
),
seller_pubkey: Some(
"fd63e2f7560577216107026fb9107b69fdb324c89bd5be676bd84a593aec21dc",
),
seller_token: Some(
972,
),
initiator_full_privacy: false,
counterpart_full_privacy: false,
initiator_info: Some(
UserInfo {
rating: 5.0,
reviews: 1,
operating_days: 11,
},
),
counterpart_info: Some(
UserInfo {
rating: 4.0,
reviews: 1,
operating_days: 11,
},
),
premium: 0,
payment_method: "test2",
amount: 500,
fiat_amount: 4,
fee: 0,
routing_fee: 0,
buyer_invoice: Some(
"lnbcrt5u1pnlazu8pp5r8krmxz4re79yvmatyhd9c23us6muytfq2mq49j0pt50p7dzppyqdqqcqzzsxqyz5vqsp5g60um8uz0n259t8fpejj67mfeaajthxwnsvndzf0amz9487frjxs9qyyssq4n9zpx90279p6l7atkuwq6rl9pm4dadgkpnvfgwkuv0rwkn5wtw8t0hq6nqjs4n3jmfvhsduct0d0vdqxg3c6sgwc6zpalpwnf9tucsp3pd6rc",
),
invoice_held_at: 1744735232,
taken_at: 1744734528,
created_at: 1744734474,
},
)
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
src/util.rs (1)
954-955: Refine error handling for order type checks.The function uses
order.is_buy_order().is_ok()instead of capturing potential errors. Ifis_buy_order()fails (e.g., due to an unrecognized order kind), the function silently treats it as a non-buy order. This risks masking logical bugs and causing misleading behavior.
🧹 Nitpick comments (2)
src/util.rs (2)
949-1023: Good implementation of the reputation notification feature!The function correctly handles retrieving user reputation and sending notifications to the appropriate parties based on order type and status.
I have a few suggestions for improvement:
The error handling for
is_buy_order()could be more explicit. Currently, ifis_buy_order()fails due to an invalid order kind, it silently treats it as a non-buy order.Consider using a constant for the seconds-in-a-day value (86400) to make the operating days calculation more readable.
- let is_buy_order = order.is_buy_order().is_ok(); + let is_buy_order = match order.is_buy_order() { + Ok(_) => true, + Err(e) => { + return Err(MostroInternalErr(ServiceError::InvalidOrderKind(e.to_string()))); + } + }; // ... + const SECONDS_PER_DAY: u64 = 86400; // ... - operating_days: (now - user.created_at as u64) / 86400, + operating_days: (now - user.created_at as u64) / SECONDS_PER_DAY,
967-971: Consider handling edge cases in operating days calculation.The current implementation assumes that
user.created_atis always less than the current timestamp. In rare cases where the created_at value might be in the future due to clock synchronization issues, this could lead to an underflow.let now = Timestamp::now().as_u64(); + let operating_days = if now > user.created_at as u64 { + (now - user.created_at as u64) / 86400 + } else { + 0 + }; UserInfo { rating: user.total_rating, reviews: user.total_reviews, - operating_days: (now - user.created_at as u64) / 86400, + operating_days, }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/util.rs(2 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (1)
src/util.rs (1)
src/db.rs (1)
is_user_present(404-419)
🔇 Additional comments (2)
src/util.rs (2)
1015-1016: Intentional omission of public key for privacy.I see that the public key field is intentionally left empty to maintain privacy, as mentioned in the PR objectives.
982-1008: Status handling is intentionally restricted.The function correctly handles only the relevant order statuses (
WaitingBuyerInvoiceandWaitingPayment) for sending reputation updates, matching the PR objectives.
* 📝 Add docstrings to `feature-full-privacy-mode-checks` (#455) * add feature to check correctly if order is full privacy or normal * 📝 Add docstrings to `feature-full-privacy-mode-checks` Docstrings generation was requested by @arkanoider. * #454 (comment) The following files were modified: * `src/app/order.rs` * `src/util.rs` --------- Co-authored-by: arkanoider <github.913zc@simplelogin.com> Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> Co-authored-by: arkanoider <113362043+arkanoider@users.noreply.github.com> * Fix network in order event (#452) Now in orers event 38383 the network that comes out is the correct one * Feature anyhow removal (#459) * remove of anyhow dependency start * removed anyhow dependecy * remove patch from cargo.toml * Update mostro-core version --------- Co-authored-by: Francisco Calderón <fjcalderon@gmail.com> * Feature disputes (#463) * Feature: dispute fix for new logic * fix for coop cancel case * Add logic for info message about dispute for solver * first working dispute info message for admin after taking disputes * added fields to dispute info message for solver * removed some probably useless and refactored a bit admin-take-dispute function * clippy suggestion * other cosmetics to admin take file * some other cosmetics on admin-take-dispute file * fix on admin-take * Update admin_take_dispute.rs * fixed a wrong search of order id in admin take file@ * Fix: added correct check to add solver from admin cli * fix: wrong check on admin cancel * Fix initiator pubkey: now is the trade key of initiator not identity * quick fix for full privacy orders * new logic with mixed full privacy - regular reputation mode * Update cargo toml to compile with version 0.6.32 of mostro-core - this is in preparation for migrating to nostr-sdk 0.40 * rollback sdk to 0.38 version to merge disputes - we will come back to 0.40 when we will fix signature issue * Update mostro-core dependency --------- Co-authored-by: Francisco Calderón <fjcalderon@gmail.com> * added correction for the case of buyer adding back a new invoice after payment failure (#462) * Fix for nostr sdk 40 issue on incoming message (#465) * testing sdk 40 * fix for sdk 40 * cleaned cargo.toml * Bump mostro core version --------- Co-authored-by: Francisco Calderón <fjcalderon@gmail.com> * fix: sends order with an updated 'status' field as the reply to add-invoice when there is a preimage (#464) * Feature-nip69-order-status (#467) * feature: align to nip69 order status in nostr event * Improved in progress nip69 logic * refined event states of the order with nip69 request * add another check to avoid multiple events with in-progress state * Privacy range order fix (#468) * add optional field for users in full privacy inside solver message * To be tested - privacy range child order fix * fix cargo.toml * bumped mostro-core version to 6.35 * New user or privacy order send same user info with zeros (#471) * new user or privacy order send same user info with zeros * fix days field and removed some println! macro with nicer tracing messages * bumped mostro-core version to 6.36 and added requested fix to compile * Add previous order state in database for solver message (#472) * add previous state in database for solver message * bumped mostro-core version to 6.36 * Taker info message to maker. I think that could be modifies in a more generic UserInfo. (#473) * added logic to send infos to maker when an order is taken * Add takers info message for maker * fix cargo.toml * set peer pubkey to empty string when notifying taker reputation to maker * moved user info message to the right point of the order flow * fix cargo.toml * changed message struct from UserDisputeInfo to UserInfo * fix: get master keys for user infos * Bumped mostro-core to version 6.38 * fix for buy order flow with message to maker (#479) * Rabbit fixes --------- Co-authored-by: Francisco Calderón <fjcalderon@gmail.com> Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> Co-authored-by: Catrya <140891948+Catrya@users.noreply.github.com> Co-authored-by: Bilthon <bilthon@gmail.com>
I think that could be modifies in a more generic UserInfo. (#473) * added logic to send infos to maker when an order is taken * Add takers info message for maker * fix cargo.toml * set peer pubkey to empty string when notifying taker reputation to maker * moved user info message to the right point of the order flow * fix cargo.toml * changed message struct from UserDisputeInfo to UserInfo * fix: get master keys for user infos * Bumped mostro-core to version 6.38
* 📝 Add docstrings to `feature-full-privacy-mode-checks` (#455) * add feature to check correctly if order is full privacy or normal * 📝 Add docstrings to `feature-full-privacy-mode-checks` Docstrings generation was requested by @arkanoider. * #454 (comment) The following files were modified: * `src/app/order.rs` * `src/util.rs` --------- Co-authored-by: arkanoider <github.913zc@simplelogin.com> Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> Co-authored-by: arkanoider <113362043+arkanoider@users.noreply.github.com> * Feature disputes (#463) * Feature: dispute fix for new logic * fix for coop cancel case * Add logic for info message about dispute for solver * first working dispute info message for admin after taking disputes * added fields to dispute info message for solver * removed some probably useless and refactored a bit admin-take-dispute function * clippy suggestion * other cosmetics to admin take file * some other cosmetics on admin-take-dispute file * fix on admin-take * Update admin_take_dispute.rs * fixed a wrong search of order id in admin take file@ * Fix: added correct check to add solver from admin cli * fix: wrong check on admin cancel * Fix initiator pubkey: now is the trade key of initiator not identity * quick fix for full privacy orders * new logic with mixed full privacy - regular reputation mode * Update cargo toml to compile with version 0.6.32 of mostro-core - this is in preparation for migrating to nostr-sdk 0.40 * rollback sdk to 0.38 version to merge disputes - we will come back to 0.40 when we will fix signature issue * Update mostro-core dependency --------- Co-authored-by: Francisco Calderón <fjcalderon@gmail.com> * Fix for nostr sdk 40 issue on incoming message (#465) * testing sdk 40 * fix for sdk 40 * cleaned cargo.toml * Bump mostro core version --------- Co-authored-by: Francisco Calderón <fjcalderon@gmail.com> * Feature-nip69-order-status (#467) * feature: align to nip69 order status in nostr event * Improved in progress nip69 logic * refined event states of the order with nip69 request * add another check to avoid multiple events with in-progress state * Taker info message to maker. I think that could be modifies in a more generic UserInfo. (#473) * added logic to send infos to maker when an order is taken * Add takers info message for maker * fix cargo.toml * set peer pubkey to empty string when notifying taker reputation to maker * moved user info message to the right point of the order flow * fix cargo.toml * changed message struct from UserDisputeInfo to UserInfo * fix: get master keys for user infos * Bumped mostro-core to version 6.38 * first commit for database encryption * Moving on with encryption work * Implemented base64 on cipher * Takebuy and takesell pending orders check now working with encryption * Removed unwraps * Finishing code: changed password management and completing checks * Finishing code: used hashset for search * added unit test for evaluate timings * first order cycle completed - to be fixed empty password case * Added logic for testing a caching idea using hashmap to speed up search of identity keys when encrypted * ready to start review process * Cleaned test * removed patch from cargo.toml * Rabbit fixes * some improvements to have also rating working with encryption * Removed useless call in db.rs * fix for tests * Cosmetics on release.rs - improved a bit a function in more ribust way * fix: wrong check on full privacy orders in disputes * fix: more meaningful variable name in dispute setup * fix: wrong commented lines reactivated * fix: some fixes in privacy orders with encryption * fix: some fixes following coderabbit advices Introduced a random delay on password entering to avoid timing attacks. Removed awaiting from store_encrypted function that does not require async. * refactor: removed many useless connection opening to database with direct use of borrowed pool variable * chore: more meaningful text for user in db.rs * chore: improved encryption unit test now fix salt for testing works - fix salt and password are used to test timings with decryption using key caching, to test it do: cargo test test_fetch_string_column_scalar -- --nocapture * refactor: some improvements in db.rs improved password error management reduce code duplication for pending orders checks * chore(rebase-on-main): commit cargo.lock for rebasing on top of main encrytpion * feat: completing refactor and rebase of encryption pr * refactor: introduced new refactoring of encryption-decryption function - cargo compiles now, we will have to create the new mostro-core after some testings. - bumped nostr-sdk to 0.41 release, no breaking changes * chore: temporary added git branch of mostro-core to compile * chore(test): fix tests * chore: bumped mostro-core version in cargo.toml * fix: wrong database path string creation * chore: fix tests in db.rs * fix: child order after a trade with a full privacy user have wrong master keys * fix: typo on check password hash function * fix: child order event after a complete order does not send user information also if order is normal (not full privacy) * fix: if a child order come from a privacy order user rating are sent in the event wit all zeroes * fix: fixed bug found by Catrya - when I recreate the child order master keys were saved without encryption so when a takesell or takebuy comes in the search for pending user orders generate a decrytpion error. --------- Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> Co-authored-by: Francisco Calderón <fjcalderon@gmail.com>
@grunch @Catrya ,
Here the pull request related in mostro-core.
here the new feature to send info message when an order taken, maker will receive something like this:
Action: TakeSell Payload: Some( Peer( Peer { pubkey: "eda23187e636a0bc21e80f37d2315b86ede4ebb3c68fedb7d72640d8c75165c0", reputation: Some( UserDisputeInfo { rating: 0.0, reviews: 0, operating_days: 1, }, ), }, ), ) In case of new user of privacy user all fields are set to 0Summary by CodeRabbit