Thanks! Yeah it's an open question for what's a better system design... In the system you're proposing, the arbiter basically has "final say" on everything... Even if they're effectively just "rubber stamping" it, they could in principle misbehave and hold things up, even if the patron says "yes the job was done to my satisfaction."
On another subject, I just happened to be thinking before this specifically about "blinded" shipments, that's a good suggestion. I wonder if there is a framework where multiple jobs could be "chained"? I.e. one "patron" is actually acting as a "free agent" for another job, etc... Although I suppose there's no need for the network to know about that.
Replies (2)
yea the "chaining" is a cool idea!
at first this protocol had many many more kinds, and fiatjaf pointed out that "everyone doesn't need to know about all this" and it was an eye-opener. as an application developer, my initial approach was to have a kind for every state transition... but that's silly. you only need events for actions that matter for the paper trail, and in some ways the fewer the better, leaves more flexibility.
agreed that the arbiter could hold things up or otherwise be Bad in many ways. that's the major trade-off that allows it to be simple and not get into smart contract, timelock or multi-sig land.
all that trust in the arbiter represents saved complexity NOT building trustless flows.
at the end of the day, I think Catallax would be best tightly coupled to #cashu. Take the trust requirements embedded in cashu, take that as the ceiling (and floor) of trust for the entite system, and sort of "clone" that trust to other domains (like the arbiter) to get more robust applications without really introducing new trust requirements.
this is one reason I think there's a good case to be made that the arbiter should also provide a mint. a mint can rug you, and arbiter can rug you... keep that risk in one party rather than multiplying the risk in many places.
