commit 27450d99d9db6a3e5a126accd4330d1b56d90ee3
parent 7847dceba0525a56ad477d9d8107ffd6f5050b1d
Author: Christian Grothoff <grothoff@gnunet.org>
Date: Thu, 12 Oct 2023 09:46:13 +0200
simplify DD46 to make it more implementable
Diffstat:
1 file changed, 18 insertions(+), 19 deletions(-)
diff --git a/design-documents/046-mumimo-contracts.rst b/design-documents/046-mumimo-contracts.rst
@@ -111,6 +111,13 @@ The contract terms v1 will have the following structure:
// encoded in it (such as a short product identifier and timestamp).
order_id: string;
+ // Price to be paid for the transaction. Could be 0.
+ // The price is in addition to other instruments,
+ // such as rations and tokens.
+ // The exchange will subtract deposit fees from that amount
+ // before transferring it to the merchant.
+ price: Amount;
+
// URL where the same contract could be ordered again (if
// available). Returned also at the public order endpoint
// for people other than the actual buyer (hence public,
@@ -271,27 +278,9 @@ The contract terms v1 will have the following structure:
.. ts:def:: ContractInput
type ContractInput =
- | ContractInputCurrency
| ContractInputRation
| ContractInputToken;
-.. ts:def:: ContractInputCurrency
-
- interface ContractInputCurrency {
-
- type: "coin";
-
- // Price to be paid for the transaction.
- // The exchange will subtract deposit fees from that amount
- // before transferring it to the merchant.
- price: Amount;
-
- // FIXME-DOLD: do we want to move this into a 'details'
- // sub-structure as done with tokens below?
- class: "currency";
-
- };
-
.. ts:def:: ContractInputRation
interface ContractInputRation {
@@ -702,11 +691,21 @@ Definition of Done
- Integration tests exist in wallet-core
- Deliverables accepted by EC
+While rationing is part of the design, we expect the actual implementation to
+be done much later and thus should not consider it part of the "DONE" part.
+Rationing is complex, especially as a refunded contract should probably also
+refund the ration.
+
Alternatives
============
-None.
+The first draft of this DD included the capability of paying with multiple
+currencies for the same contract (for example, USD:1 and EUR:5) plus tokens
+and rations. However, this is very complex, both for wallets (how to display),
+for other merchant APIs (does the refund API have to become multi-currency as
+well?) and there does not seem to be a good business case for it. So for now,
+the price is always only in one currency.
Drawbacks
