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.
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
reply
In my view, the ecrow provider is the centralized point. There isn't much of a functional difference in if they have a website or not.
Now, to be fair to you, you said you didn't need a centralized backend as in infrastructure so yeah I mean you could do this in person right.
I think there's a lot of not seeing the difference between federated things for example and decentralized things in our usual sphere of influence and I think that is caused by marketing teams often which has gotten to the point of confusing all of the people within our general sphere who are influenced by those marketing teams. So the way you deconstruct all of that is to reject it. So I'm sorry if this feels like I'm being silly and making unnecessary commentary, but I do feel like its necessary.
reply
I agree with almost all of what you say here and I hope I also live up to my duty (as I perceive it) of calling out the error of treating federated solutions as decentralized
I do, however, think "not having a website" makes a big functional difference. If people pick escrows through an informal mechanism (e.g. "well we both know Bob, Bob is awesome. He wouldn't cheat either of us. In fact, let's just ask him if he'll do this for us") then no one except the interested parties ever has to know Bob did anything.
reply