More mockups! I’m assuming we add an optional “Manual Confirmation” feature, let’s se…
Transactions
The list of transactions could look like this:
SRS Flow
Since we can now manually accept transactions, we can see a new button: “Accept”. “Complete” is the same as “Finalize”; “Reject” and “Cancel” means that we’re either rejecting the incoming transaction or canceling the unfinalized transaction.
When we click on “Complete” it is the same process of what we know now as “finalize”.
The new thing is the manual confirmation. When we click on “Accept” we are able of confirming the amount and the receiver address.
After accepting the transaction, our wallet will try to communicate via Tor with the sender, if everything goes well, we see something like this:
Well, the reality is that things can go wrong, and probably we could not reach the sender. In this case, we will need to manually share the signed transaction agreement with the sender.
RSR Flow
We could have also invoices. From the wallet we can:
- Generate invoices
- Pay invoices
When we generate an invoice, we will have an transaction pending for payment (Payment Requested), we need to wait for the sender to pay the invoice; this invoice then can be manually completed when the sender shares the transaction agreement aka slatepack with us. Invoices can be also canceled.
In order to register the payment, we should accept the transaction agreement signed by the sender:
If we receive an invoice, we have a transaction pending for payment (Payment Pending); we can decide to pay it, but also, we can just reject it.
After clicking on “Pay”, we try to communicate via Tor with the receiver, if something goes wrong, we then should share the transaction agreement manually.
Conclusion
Having both flows together (Sender-Receiver-Sender and Receiver-Sender-Receiver), in addition with manual confirmation for SRS, looks pretty similar. I don’t think it will add any confusion at all, we just need to be less technical and pick better wording to describe the transaction building process. Maybe “Add Signature” is over simplifying, that’s why “Add participant data” sounds a bit more accurate. We can keep iterating until we find a better way to describe things for the regular user. Achieving this will require to define and pass some RFCs, but again, I think it is worth it.