Add the option for users to see all their current orders

[Catrya]

If a user has several orders in different statuses, it is likely that they will forget some or find it difficult to remember them all.
I suggest adding the option so that users can see a list of all the orders they have that are not in status: canceled, success, canceled-by-admin or settled-by-admin

[Catrya]

Hola @josefinalliende los usuarios deberían ver un listado de las órdenes que tengan en los siguientes status:

• pending
• waiting-buyer-invoice
• waiting-payment
• active
• fiat-sent
• dispute
• settled-hold-invoice

Por ahora todos esos status se publican en los eventos 38383, aunque dispute se publica en otro evento aparte que no lo relaciona publicamente a la orden

[josefinalliende]

Thanks @Catrya for the explanation!!

[josefinalliende]

I've encountered a challenge with filtering user orders for mostro-cli, and I might be misunderstanding some aspects, but it seems to me that with NIP-59, this might no longer be possible to identify in a reliable way which orders are owned by the user.

What I understand of the flow is:

• The user sends a new order event using NIP-59 with an ephemeral key.
• Mostro sends a confirmation message with NIP-59 to the user. (currently in mostro web is using this confirmation message to determine if an order is owner by the user)
• Mostro then publishes an order event that doesn’t include information about which user created the order (Am I missing something here?)."

The issue as I see it:

• Giftwrap events aren’t necessarily stored by relays, making it difficult to reconstruct which orders are from the user using the the confirmation message sent by mostro. Or al least this is what I understand of this phrase of NIP-59. “Relays may choose not to store gift wrapped events due to them not being publicly useful” of NIP-59 https://nips.nostr.com/59#other-considerations .
• The order event published by Mostro doesn’t contain any information indicating which ephemeral pub key created the order.

If I'm understanding this correctly, a few things would need to happen to identify which orders are of the current user:

• The order event should include something (though I’m not entirely sure what) that allows the user to distinguish their orders but means nothing for the rest of the users and doesn't leak information —for example, a hash of the ephemeral pubkey included in the content.
• The client should store the ephemeral keys it creates or be able to generate them deterministically from its private key to then check if the order events are owned by the current user.

[Catrya]

What about that clients stored the IDs of the orders they created and instead of making a request to Mostro, they looked for the status of that orders in Nostr events 38383? It's just an idea, @grunch @arkanoider or @bilthon could tell you better.

[josefinalliende]

I think mostro-web is doing what you're proposing, @Catrya, and it works. But, if I'm not mistaken, it requires the relay to store the gift wrap messages if you want to be able to access it form another tab or client with the same keys. What I understand is that the order ID is not generated on the client side but in mostro, so that ID would be received in the gift wrap 🎁 confirmation message that mostro sends to the client.

Perhaps the point is simply that we can assume that the relays connected to mostro's clients will store the gift wrap messages?

[Catrya]

Perhaps the point is simply that we can assume that the relays connected to mostro's clients will store the gift wrap messages?

Well I checked and in relay wss://relay.mostro.network there are nip59 events from more than 1 month ago, I don't know how long they will store them, but I think it's enough time to make a request for the status of an order, since an order doesn't last long open, it's limited by how long the hold invoice that the lnd node creates lasts, and in pending status let's say it's 1 day, so an order shouldn't last more than 2 or 3 days from when it's pending until it's successful or canceled, in case payment to the buyer fails and the order remains open for more days, perhaps it will be resolved in 1 week at the most.

[arkanoider]

I think mostro-web is doing what you're proposing, @Catrya, and it works. But, if I'm not mistaken, it requires the relay to store the gift wrap messages if you want to be able to access it form another tab or client with the same keys. What I understand is that the order ID is not generated on the client side but in mostro, so that ID would be received in the gift wrap 🎁 confirmation message that mostro sends to the client.

Yes, you are right @josefinalliende order_id is a Uuid generate from mostrod when a gift wrap with a valid order inside is received. You are correct also when you say we send back an ack message with order infos.

Perhaps the point is simply that we can assume that the relays connected to mostro's clients will store the gift wrap messages?

This is the idea, relays COULD not store the nip59 messages, but we should avoid using that relays, consider that a Mostro admin could have his relay running and accepting only messages for mostro ( this is what are doing our test relays now ).

[arkanoider]

I've encountered a challenge with filtering user orders for mostro-cli, and I might be misunderstanding some aspects, but it seems to me that with NIP-59, this might no longer be possible to identify in a reliable way which orders are owned by the user.

What I understand of the flow is:

• The user sends a new order event using NIP-59 with an ephemeral key.
• Mostro sends a confirmation message with NIP-59 to the user. (currently in mostro web is using this confirmation message to determine if an order is owner by the user)
• Mostro then publishes an order event that doesn’t include information about which user created the order (Am I missing something here?)."

You are right, that is the flow. We did not want to show user info on event sent to relays, infos published with a new order are represented with this list of tags:

pub fn order_to_tags(order: &Order, reputation: Option<Rating>) -> Tags {
    let tags: Vec<Tag> = vec![
        Tag::custom(
            TagKind::Custom(Cow::Borrowed("k")),
            vec![order.kind.to_string()],
        ),
        Tag::custom(
            TagKind::Custom(Cow::Borrowed("f")),
            vec![order.fiat_code.to_string()],
        ),
        Tag::custom(
            TagKind::Custom(Cow::Borrowed("s")),
            vec![order.status.to_string()],
        ),
        Tag::custom(
            TagKind::Custom(Cow::Borrowed("amt")),
            vec![order.amount.to_string()],
        ),
        Tag::custom(
            TagKind::Custom(Cow::Borrowed("fa")),
            create_fiat_amt_array(order),
        ),
        Tag::custom(
            TagKind::Custom(Cow::Borrowed("pm")),
            vec![order.payment_method.to_string()],
        ),
        Tag::custom(
            TagKind::Custom(Cow::Borrowed("premium")),
            vec![order.premium.to_string()],
        ),
        Tag::custom(
            TagKind::Custom(Cow::Borrowed("rating")),
            vec![create_rating_string(reputation)],
        ),
        Tag::custom(
            TagKind::Custom(Cow::Borrowed("network")),
            vec!["mainnet".to_string()],
        ),
        Tag::custom(
            TagKind::Custom(Cow::Borrowed("layer")),
            vec!["lightning".to_string()],
        ),
        Tag::custom(
            TagKind::Custom(Cow::Borrowed("expiration")),
            vec![(order.expires_at + Duration::hours(12).num_seconds()).to_string()],
        ),
        Tag::custom(
            TagKind::Custom(Cow::Borrowed("y")),
            vec!["mostro".to_string()],
        ),
        Tag::custom(
            TagKind::Custom(Cow::Borrowed("z")),
            vec!["order".to_string()],
        ),
    ];

    Tags::new(tags)
}

This is just the event published on Nostr, but mostro saves internally in the db the creator pubkey so we should be able to request orders created by a user. @grunch will confirm this or not ( I could be not remembering correctly, but I think we internally know the creator). Just speakin loud anyway...
Another consideration, we are slowly shifting from the idea of inserting a pubkey in mostro-web, we prefer a general random address for every order probably. Or just users who wants to use always the same key will use this, but speaking from a privacy point of view being just a different random string everytime is a good idea imo.

The issue as I see it:

• Giftwrap events aren’t necessarily stored by relays, making it difficult to reconstruct which orders are from the user using the the confirmation message sent by mostro. Or al least this is what I understand of this phrase of NIP-59. “Relays may choose not to store gift wrapped events due to them not being publicly useful” of NIP-59 https://nips.nostr.com/59#other-considerations .

Still right @josefinalliende , but we should only use relay that save nip59 events.

• The order event published by Mostro doesn’t contain any information indicating which ephemeral pub key created the order.

Right! We want it this way.

If I'm understanding this correctly, a few things would need to happen to identify which orders are of the current user:

• The order event should include something (though I’m not entirely sure what) that allows the user to distinguish their orders but means nothing for the rest of the users and doesn't leak information —for example, a hash of the ephemeral pubkey included in the content.
• The client should store the ephemeral keys it creates or be able to generate them deterministically from its private key to then check if the order events are owned by the current user.

I think, as I said above, that we could be able to request from mostro-cli the orders created by a specific pubkey. We never used that filter, because cli is still a nerd tool we are moving to more simple tool to create orders and make trades.

[bilthon]

The way the mostro web tells a user's orders apart from all others is by detecting the order creation ACK messages. This diagram kinda highlights this.

This is just a way of doing it. Another alternative would be to have a local store of the user's order ids, again making use of the ACK message sent by mostro when creating an order.

[josefinalliende]

Thank you so much @Catrya @arkanoider @bilthon for the thorough explanation ❤️. Understanding that 'we should only use relays that save NIP-59 events' really clears up my doubts. I truly appreciate the time you took to walk me through this!