Five on Nostr: Thanks! I read most of the spec. So I understand this is a great improvement if p2p ...
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!
Published at
2025-03-31 20:06:11Event JSON
{
"id": "e7e82f0118b6c5e2c5c0286cf6775a5a2d3228168232fc4c9ff55c63d32677ce",
"pubkey": "d04ecf33a303a59852fdb681ed8b412201ba85d8d2199aec73cb62681d62aa90",
"created_at": 1743451571,
"kind": 1,
"tags": [
[
"e",
"f6cb9697c3484c373494107b826371485edf44e36e06cf27c382c0e76371f811",
"",
"root"
],
[
"e",
"965bfe0eff9ad22931534205327b4a857e38a6de0b1e78b5112e637bdb33d141"
],
[
"e",
"6c10cf45b3e7196b33be2d62a881e63a887203461395a83a84d182748440a1c0",
"",
"reply"
],
[
"p",
"dbe0b1bdbe129ce38db753d6a997e6a29e693afd02aa1d1f9b005fa7386e5c26"
],
[
"p",
"d04ecf33a303a59852fdb681ed8b412201ba85d8d2199aec73cb62681d62aa90"
]
],
"content": "Thanks!\nI read most of the spec.\nSo 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.\n\nI 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:\n\n1. I create a maker order on *my relays*.\n\n2. 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) . \n\n3. 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)\n\n4. Mostro instance concludes our trade the way it's described in the spec\n\n- We can communicate via nip17 DM chat during the whole trade.\n- 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.\n\nPrivacy: 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.\n\nOverall 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. \nCan you explain why you made this decision or misconceptions in my understanding? Many thanks!",
"sig": "2f9de420323e5b5eba779207ce9ab942d0edbfdbb733521bb9f2caf3365372b727f9605a3f86b4f52328336b677104ca4db091836ae4cc5c3acf89080af56aba"
}