Replying to Avatar Five

Thanks!

I read most of the spec.

So I understand this is a great improvement if p2p platforms unite around a common protocol (nostr) on how to do this. Seems like the spec covers most possible scenarios of a trade.

I am still wondering if a Mostro needs to hold the orderbook. I think essentially a Mostro is a P2P LN escrow. But it also handles order making/taking and DMs. I thought these functionalities could be achieved without a Mostro instance:

1. I create a maker order on *my relays*.

2. Alice finds my order (by requesting for this kind of event, possibly filtered by web of trust or pow or whatever mechanism) and takes it (publishes the taker event on nostr on my read relays) .

3. We send our trade details to a Mostro instance to its relays. Most likely the maker would decide about the specific Moatro in the order. He can only select a Mostro that has the right params for the trade (e.g. within the order amount limit)

4. Mostro instance concludes our trade the way it's described in the spec

- We can communicate via nip17 DM chat during the whole trade.

- We can rate each other and Mostros as well. Ratings are also filtered by web of trust of the logged-in user to prevent gaming reputation.

Privacy: I think gift-wrapped orders don't really _add_ to privacy because they are publicly available in reality. Anyone can download the order book from a Mostro. I Iike the ephemeral nostr key option though.

Overall I just still don't see the purpose why Mostro-s must handle so much and be middle-men for the non-financial part of the trade.

Can you explain why you made this decision or misconceptions in my understanding? Many thanks!

This link provides the simplest explanation of how it works: https://mostro.network/docs-english/how-it-works.html

When a user creates an order, the Mostro instance where it was created publishes a kind 38383 event to the relays decided by the administrator of that Mostro instance. Clients search for these events to display an order book to users. Users should be able to filter within the clients if they want to see all existing orders or only those corresponding to a specific Mostro instance.

The chat between users is not managed by a Mostro instance, but by a Mostro client, and does not share any information with the instances.

The way the mobile client and other initial clients are being developed is to use ephemeral keys and this type of chat https://mostro.network/protocol/chat.html so that if users have a dispute, they can show the chat to an admin without compromising the privacy of identities before or after that trade.

But if someone were to create a Mostro client that didn't use that chat, it would still work because the Mostro instance isn't interested in how users communicate. However, it's difficult for a Mostro client to become widespread if it doesn't provide a good UX and privacy for solvers and users to resolve disputes as it is doing with https://mostro.network/protocol/chat.html

Reply to this note

Please Login to reply.

Discussion

I like the p2p chat. The arbitration explains why the shared key is necessary.

I gather the orders published on Mostro relays rather than user-defined relays saves a few roundtrips and so it's for simplicity.

Thanks for the explanation!

Your questions were very good. Thanks!