Replying to Avatar Mostro

I encourage you to read the Mostro documentation to better understand how it works😃

For Users:

https://mostro.network/docs-english/

Client Devs:

https://mostro.network/protocol/

https://github.com/MostroP2P

Mostro is a protocol, and to use it, you must use a client (mobile, CLI, web, or any other).

When there are multiple Mostro instances, their operators can use any relays they want, and users can connect to the relays they want, depending on which Mostro they want to use.

If you have any questions, just keep asking.

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!

Reply to this note

Please Login to reply.

Discussion

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

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!

Testing zaps on this note… we made seven attempts to⚡zap this note, at five@npub.cash, over a period of 1 day. All seven attempts were successful. You should check on your end to be sure you received these. Average zap time was 2931ms (2.9 seconds). We consider this zap time slow... generally, zaps should complete in under two seconds. (Other Nostr users might think your zaps are broken, might not zap you again.) We recommend you receive zaps with a well-connected, cloud-based Lightning node to reduce inbound zap latency.