Interesting. But, it wasn't clear who picks the Arbiter. What's stopping the Patron or even the Free Agent from also becoming an Arbiter and scamming people by falsely approving or denying the monies held in escrow?

Badass!

Ah, something for the FAQ! The Patron and the Arbiter agree together and the Patron seals the deal by funding the escrow. You are right about this though: in the most anonymous mode, a single human can pretend to be two different roles (Patron + Arbiter) and trick a Free Agent into submitting work and then "refunding" the money (back to himself). With a proper reputation system this scam won't last long - maybe one or two low-paying gigs. But if someone is operating NON-100% anonymously, it would be obvious. If I, Vinney, am the Patron, and, say, @PABLOF7z is the Arbiter, we clearly are different people.

Right, so in the example you've cited you're trading on the previously established reputations in Nostr to show that you and @PABLOF7z are different people...

You made it to the FAQ :)

Catallax - A Protocol for Pseudonymous Contract Work Economies

Catallax is an open protocol that enables pseudonymous contract work economies. It runs over Nostr, Bitcoin and Cashu ecash for censorship-resistan...

This is really cool, exactly the kind of thing "only Nostr" can do. My first glance question is: Isn't this an ideal application for multisignature Bitcoin? This is basically a 2-of-3 transaction between buyer, seller and arbiter. Also is "Kind 3400" already in the protocol or something you came up with? Are / should transactions be linked to these Nostr events directly in some way?

yep! and in a perfectly pseudonymous world, if we have GrapeRank or another reputation system, you could get the same after some history of pro-social action on the protocol. (or even without those automated systems, clients could try to show histories nicely)

These kinds are in a NIP I proposed (which is a bit outdated now). it's linked on the site. You're right, this would be great for multisig. Someone could build that version. I want the base layer to be as simple as possible - and if we leave multisigs out of it we get #cashu nutsack wallets for new users on day one. (cc @calle )

The multi-sig question is another good one for the FAQ, thanks.

Ooh I’d love to see if there was any way to develop a Nostr-version of Bisq2 using this application 👀

oooo.... are you familiar with bisq2? I'm not but would be open to hearing about it

It's in the FAQ now. Thanks!

Great question! I've got a long (edit: VERY long!), many-pronged answer for you :) The best answer is that the protocol doesn't enforce this and the three parties involved could choose to do exactly what you're saying. As I fill out the site more I'll be sure to include this important detail, so thanks very much for that. The arbiter might advertise that they _don't_ judge work and the patron might make clear in their project description that they also work this way. In that case, the agent would send their work directly to the patron and then all three would need to coordinate with the arbiter to get the escrow released to someone. The only thing the protocol expects is that _the arbiter_ is the one who creates the "job done" event and attests to the final conclusion and escrow release receipt. There's a tightrope walk between making the protocol too opinionated such that it gets in the way, vs making it so loose that it doesn't provide any tools for consensus. That said, I personally think keeping the arbiter "in the loop" as a judge is likely to yield better outcomes: - Domain expertise for adjudication. If an arbiter is only doing dispute resolution, they'll still need to have domain expertise. If the patron and free agent come to the arbiter with a dispute about some implementation detail of a technical system, the arbiter is going to need to understand it to make a decision. By agreeing to judge the work itself, the arbiter is solidifying a promise about their domain expertise. - It allows for a **patron** who _doesn't_ have domain expertise! Imagine a patron who has a lot of money, likes a particular open source nostr client, but doesn't know a thing about programming. He could request a feature, described in grug-brain language, "me want big blue button here that make picture". This clever patron selects the _high profile developer_ of the open source client as the arbiter. Now we're in interesting territory... The patron gets his button, the agent gets paid, and the arbiter/open source developer basically gets a PR/contribution to review (either to the upstream project or a personal fork for the patron). **He's getting his FOSS project extended without spending any money - in fact he makes money off arbiter fees.** Sure, maybe this sets up new and bizarre incentives or cheats - but that's part of the fun! - Last one because I wrote way too much here. The are many specific cases in which it is beneficial for two strangers to have a trusted third party in the loop: one example is "anonymous" shipping. Say I want to buy some stuff off @Shopstr Markets but I'm paranoid about leaking my address. Imagine there is a super high-profile and trustworthy arbiter out there who I think is _less likely_ than the vendor to dox me. I create a task to get the product to me (as a patron), with the vendor as the free agent and the trusted "shipping intermediary" as the arbiter. I pay ("escrow") the arbiter for the product, the free agent "does the work" of shipping **to the arbiter**. I've already trusted the arbiter with my address (privately), so they ship the product to me and release the funds to the vendor. I would expect to pay high arbiter fees for this incredible service that I can't get elsewhere! In the last example, providing some basic protocol features that _allow_ (or at least don't preclude) the arbiter from being deeply in the loop creates opportunities for people to build creative service businesses. I'm sure people will come up with even more surprising ones, and I hope they build custom client apps for their weird things, and I hope they contract out the software work via Catallax. Happy to keep answering more as you've got them. This is really helpful for me not only as a guide to content the site needs, but in the actual protocol design, which should absolutely be a result of many open discussions!

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.

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.