for invoice (receiver-signs-last) flow.
These names are somewhat arbitrary, and finalize has been criticized for not being an obvious necessity.
For invoice flow, the following names are more descriptive:
request-payment
offer-payment
accept-payment
Is is possible to replace “payment” by another word that would be appropriate for regular flow?
I thought “invoice” might work, but hesitate to use that word in the non-invoice flow:-(
How about expense?
Btw, I hope that invoice flow becomes the standard, and reserve regular flow for cases where a high-volume transactor, such as an exchange, insists on being last-to-sign to minimize output locking.
2-step flow doesn’t seem to be “around the corner” so we can definitely improve our current 3-step flow.
I think request, offer, accept are definitely better words for invoice flow and the ‘finalize’ now actually makes sense.
Would be nice if we found names that fit both flows
Definitely in favor of using request - offer - accept.
Personally I think it does not matter much whether grin or payment is used, but grin is shorter and therefore might sound better.
In case of two steps, it matters of course who initiate what naming would be correct. offer - accept
would be most fitting if the sender initiates, request - send
would be best in the case of the invoice workflow, I mean offer would not make sense here since the transaction is automatically accepted.
Most coins use send receive, this would be most ideal, make it magic happening in the background (yes I know the receive part is much different from coins with adresses, not important). Request - send in the case of invoice. The problem is that slatepacks require the user to be conscious about the number of steps in which case for three step transactions other terms are needee
I think the words send and receive should be avoided for naming, because they can confuse users to think that the transaction is completed after sending an amount.
The finalize step should be eliminated if possible, because from a UX perspective it does feel bureaucratic - in the first two steps a transaction is invoked and accepted, so from a user’s perspective everything is already said, but grin still requires a finalization step. As long as that cannot be eliminated, I think finalize is already the best name for that step.
The problem here is that the word “accept” in your 2nd step suggests that you already got the grins, when you really have 1 more step to do. This is the main confusion with the current 2nd round name (receive/pay) because their names suggest that the flow is finished which is why the last step “finalize” is confusing
Maybe something along the lines of Allow other party to deposit amount X on your account and Allow other party to withdraw amount X from your account. Much longer though.
I dont think accept means you already have it. If you accept a collect phone call the next step is connecting the call, if you accept a new job you are not instantaneously working there. It means you approve of the circumstances and want to move forward.
Maybe but it also doesn’t mean that there’s something more to do. You can accept an apology and nothing needs to be done after. I’m not a native english speaker so this could be an issue on my part, but I’d be confused if I agreed with someone to send me 2 coins, then I said “accept” to these 2 coins and the 2 coins were not there. Accept as a word on its own doesn’t imply a next step, while “offer” does I think.
I think that offer and accept are the perfect words to describe the (first) signing and the counter-signing of a transaction, since an offer is never complete without acceptance.
I agree, Accept works as alternative to finalize IMO and is perfect for both 3 step invoice.
request-offer-accept (on chain)
and perfect for normal 2 step transaction
offer-accept (on chain)
For 2 step invoice I would suggest request-send (on chain)
For 3 step transaction offer-accept-send (on chain)
-a bit confusing since accept in this context does not broadcast the transaction🤔
To make thing more clear just add the explenation that send and accept involve publishing/broadcasting the transaction, putting the transaction on chain.
The only downside is that there are now two words for putting a transaction on chain while with finalize we only need one word since there is no directionality involved. Other words that share this characteriatic with finalize are publish and broadcast.
Still I think using accept and send is more intuitive to most users.
I expect 2 step transactions will become standard and 3 steps will be used by more knowledgeable Grin users for who the names are not that important. Or is the plan to switch to 2 step transactions altogether for transaction monotonicity?
2-step and 3-step don’t impact tx monotonicity, they just have a different way of creating a tx, but the txs keep the same rules.
There is no agreed on plan for a 2-step solution as far as I’m aware, we just seem to agree that 2-step is better. We’ll hopefully research further the ideas that have been shared for 2-step👍