Hey sorry for the delayed response, just seeing this now!
Like you said, centralization is a concern with this model - so that’s a non-starter for me when we’re trying to build a fully interoperable infinite bazaar with multiple service providers operating permissionlessly on the network.
The other thought I immediately have is: as a service provider I do not want to be responsible for this infrastructure because of the liability. By inserting myself into the transaction with a service like this I’m all of a sudden responsible for if orders get fulfilled or not. In the current model I am hands off- I don’t control the protocol and it’s P2P. I know your design sketch is making it so I basically can’t see anything ever, but I am still RESPONSIBLE for message delivery once I provide a service like that.
I think a mix of message types will solve this eventually, NIP-17 for some event types, Marmot style messaging for others, but right now it’s hard enough to even just get everything coordinated thru NIP-17… adding complexity before we have a real problem to solve is a foot gun I am perpetually trying to avoid!!
EricFJ
npub10x…2g437
2026-05-14 15:33:56 UTC
in reply to nevent1q…xw2t
Author Public Key
npub10xvczstpwsljy7gqd2cselvrh5e6mlerep09m8gff87avru0ryqsg2g437Published at
2026-05-14 15:33:56 UTCEvent JSON
{
"id": "d873e1dad86a3bb3083ed62c595cc0c5776f06399300a457d8a214f226aade17",
"pubkey": "7999814161743f2279006ab10cfd83bd33adff23c85e5d9d0949fdd60f8f1901",
"created_at": 1778772836,
"kind": 1,
"tags": [
[
"e",
"a4e6b7835bc5b60a8c9f07c8f7e5ac071954231873f3db554fd24ba412cb84ff",
"",
"root"
],
[
"e",
"653ceaa8ecd569493d7b63bd4e9d062cc1a9e7df6de2ac1324d38cb9fe258de3",
"",
"reply"
],
[
"p",
"35171ad8cdf177aa7818e383510c81215675d73a25a14174326778a2ade6623a",
"",
"mention"
],
[
"p",
"7bdef7bc4678de215f6fd2c71516632a7a458e8b6fd35d96cff7d9fd266055af",
"",
"mention"
]
],
"content": "Hey sorry for the delayed response, just seeing this now!\n\nLike you said, centralization is a concern with this model - so that’s a non-starter for me when we’re trying to build a fully interoperable infinite bazaar with multiple service providers operating permissionlessly on the network. \n\nThe other thought I immediately have is: as a service provider I do not want to be responsible for this infrastructure because of the liability. By inserting myself into the transaction with a service like this I’m all of a sudden responsible for if orders get fulfilled or not. In the current model I am hands off- I don’t control the protocol and it’s P2P. I know your design sketch is making it so I basically can’t see anything ever, but I am still RESPONSIBLE for message delivery once I provide a service like that. \n\nI think a mix of message types will solve this eventually, NIP-17 for some event types, Marmot style messaging for others, but right now it’s hard enough to even just get everything coordinated thru NIP-17… adding complexity before we have a real problem to solve is a foot gun I am perpetually trying to avoid!!",
"sig": "2282271b1d10126ce938179461a49d9539f7b9640c6484d944ff5b136f7e22b1d6c3e0bca1a6d2d53181ce11b8388a00c2ce0e794eee50e39080a00a2ec0e43e"
}