First, would the recommended approach be to add calls to the API? For example, a call that allows low-level crafting of the transaction or at least the script could be used by multiple UI's so that the presentation is separated from the inner workings.
What you said is essentially what I envisioned. Any kind of multi-sig transaction can be serialized in this way, and then anyone who follows this wannabe-standard can interoperate with others who do the same. If someone wants to set up a service for exchanging these blocks, they can, or someone can just make a client that recommends sending them inline in emails. I just wanted to define a consistent way to circulate information that works in ASCII fields and is usable by even the most lightweight clients (no blockchain needed, to use sign it).
Second, the case of buyer-seller-mediator can be handled with a 2-of-3 signature transaction. My question is: does the mediator get paid in a separate transaction? What if the mediator expects a small fee if the transaction goes properly, and a larger one if he has to intervene?
I don't know if I'm at the bleeding edge of this field, but I envision that there would be a third-party service that freely gives out addresses. The buyer will put up 110%-120% of the cost of the merchandise into the multi-sig tx, and then the buyer will get that 10% back when the transaction is complete (thus giving him incentive to finish the transaction, even after he receives the goods/service). If something goes wrong, the buyer and/or seller can contact the third party to mediate, and the third party would get the 10%. It's only when something goes wrong that the mediator gets involved or gets any money.
Arguably, this isn't
ideal because it means the buyer is always paying for the mediator. You could have buyer and seller both put up 5%-10%, but that would require another multi-sig tx in order to seed the transaction, in addition to the one to unlock the funds afterwards.