There is a way to do this without a centralized backend
My celebrity escrow project (live now!) lets users gamble using just a single html file and some bitcoin, and it's perfectly safe to self host that one file
The counterparties have to agree on who to use as the backup key in case there is a dispute, but that person only learns there was a bet if there happens to be a dispute -- and doesn't need to download or host any software to resolve it and collect their fee
The random person getting a notification that there's a bet dispute to resolve deciding they're too busy for all that
reply
Three mitigations:
First, the two players have to agree on what fee the escrow should get in case of a dispute. Make it worth his while or don't sign the contract.
Second, the two players also have to agree on who to use as escrow. If you pick an escrow and choose someone who you aren't sure (1) they will respond (2) honestly...well, then that's probably your fault.
Third, since escrows earn money, they are incentivized to advertise themselves and their rates. They can even charge up front: "if you want to include me in a contract, first pay me 200 sats here <insert-url>, then include a proof of payment in your contract, and offer a 10% reward for settling it honestly. If you have a dispute I will first check if you paid me in advance, then I will check if you paid me 10% in-contract. If both things check out I will pick a winner within 24 hours of receiving your contract."
reply
And so these professional escrow providers might have a centralized backend (their website) and for the sake of customer retention also have a list of bets you can participate in andddd we're back to a website with better custody than any other website, but still centralized lol.
This is the "NOSTR is not decentralized" rule. The ability to hop to as many websites as you want does not make it decentralized. So that's why I'm saying lets just be honest about what the trust assumptions are.
reply
these professional escrow providers might have a centralized backend
And they might not. If someone decides "hey I will run a website!" that does not make a protocol centralized. That website might get taken down, and the escrow might get arrested, but the protocol is still fine and works perfectly well without that particular escrow or their website. Though I do need to implement a backout clause so that if your escrow disappears and you can't come to an agreement, both parties just get their deposits back.
The ability to hop to as many websites as you want does not make it decentralized.
You don't need any websites. If your point is "things can't be decentralized if they have nostr as a dependency," then I agree. And I suppose that means I was wrong to say celebrity escrow lets you do this without a centralized backend, since it requires nostr, which is the same thing as saying "it requires a centralized backend." But in theory it doesn't require nostr -- that's just how I implemented it, because it's easy. The only requirement (theoretically) is a way to communicate with whatever escrow both parties agree on, and that does not require anything centralized.
reply
While we're here, what are we going to do about the potential for out of band payments? Sore loser decides if they bribe the escrow provider they can still make out with the money kind of situation
reply
I think this is covered by my second mitigation:
Second, the two players also have to agree on who to use as escrow. If you pick an escrow and choose someone who you aren't sure (1) they will respond (2) honestly...well, then that's probably your fault.
reply
So trust. Reputation. I'm only asking for honesty. This whole post I was just asking for honesty. Can we be honest about what we're talking about building now?
reply
if you find something dishonest in what I said, please point it out