search

TBD54566975 / tbdex

56 stars 26 forks source link

Consider splicing `Close` into two separate semantic use cases #255

Closed KendallWeihe closed 8 months ago

KendallWeihe commented 8 months ago

From here:

Do we allow Close after Order but before OrderStatus?

I'm going to work under the assumption the answer to that question is no. If the answer is yes, then it weakens my points below but nevertheless I'll make them 😃

There are 2 overarching phases of an exchange:

  1. Negotiation (RFQ and Quote)
  2. Execution (Order and OrderStatus)
KendallWeihe commented 8 months ago

Under the consensus of https://github.com/TBD54566975/tbdex/issues/242 we could have a Close in both of the 2 phases describe in the description.

Example 1

Alice: RFQ
Alice: Close (whoops jk, don't send me a quote)

Example 2

Alice: RFQ
PFI: Quote
Alice: Order
PFI: OrderStatus x n
PFI: Close

My argument is, using Close across both phases is a semantic conflation which will serve to confuse the DX. A confusion which will be further exacerbated by the rule "Close can't be sent after an Order"; meaning, a Close can be sent across both phases, but only at certain points within each given phase.

One may approach tbdex and first see that a Close can be used to cancel an active negotiation and solidify that in their mind, only to later come across, "oh so that message is also used at the end of every exchange regardless of the result." So it's the same name for two distinct semantic use cases.

The two use cases being:

  1. To cancel/reject an active negotiation
  2. To establish the execution as completed (no further messages may be sent)

Furthermore, I think it's slightly a confusing DX for the PFI to define their set of OrderStatus's which at first glance would logically include a COMPLETED status, but then also have to include an additional Close (another semantic duplication).

Working on a proposal, will publish in a subsequent comment 😃

KendallWeihe commented 8 months ago

Haven't forgotten about this, but have had my hands full

The TL;DR will be that we can implement a new message type called Cancel and then still use Close. Cancel will be for terminating during the Negotiation phase, and Close will be for the execution phase.

Two additional thoughts:

  1. Can we send a Close after an Order but prior-to an OrderStatus
  2. There's still a slight semantic duplication across the PFI-defined OrderStatus which represents a completed state, while also required the terminating Close message (diagram below to illustrate this -- IMPORTANT: disregard this being a proposal, as I'm not sure what the solution to this would be, if there even is one)

image

mistermoe commented 8 months ago

There's still a slight semantic duplication across the PFI-defined OrderStatus which represents a completed state, while also required the terminating Close message (diagram below to illustrate this -- IMPORTANT: disregard this being a proposal, as I'm not sure what the solution to this would be, if there even is one)

resolution to ^ here: https://github.com/TBD54566975/tbdex/issues/258#issuecomment-1981801577 and here: https://github.com/TBD54566975/tbdex/issues/242#issuecomment-1977002689

thanks for all of the effort you put into driving discussions about this @KendallWeihe ! going to close this one out for now. feel free to re-open with narrow scope if/when further discussion is needed