Chat commands.md

Chat commands are:

• only available in 1x1 chats
• identified by a global unique verb
• associated with a list of arguments
  • typed : free (string, float, int), constrained (query result)
  • can trigger a suggestion component : reuse regular list components?
  • trigger a callback when fired (call an events, visual feedback? always send a message?)

These constraints over-fit the currently available three commands.

only available in 1x1 chats

why?

identified by a global unique verb

makes sense

associated with a list of arguments

yes, also we've repeatedly had requests for optional arguments. e.g. if I /send SNT and then press send, I'd get to the Wallet Send screen
with recipient and asset pre-selected but amount left for me to type in.

typed : free (string, float, int), constrained (query result)

not sure I understand what's typed here, arguments?

can trigger a suggestion component : reuse regular list components?

yes, but we should allow a free form (or at least free text) suggestion. e.g. list component fits the "combo box" model fine, but sometimes
we really only want a regular text input and some text explaining the context for the user. This is not visible right now because suggestion box for the amount param hasn't been implemented yet, but it should contain the fiat value of chosen amount, no not a selection from a list.

trigger a callback when fired (call an events, visual feedback? always send a message?)

I actually wouldn't couple messages with commands at all. It should be possible to programmatically send any message type with any data, be it from a command or not.

Optional arguments make sense but might be tricky to implement e.g. probably only last ones should be optional, or careful with types.

I actually wouldn't couple messages with commands at all. It should be possible to programatically send any message type with any data, be it from a command or not.

Right

yes, but we should allow a free form (or at least free text) suggestion

Exactly that was my point about typed arguments. string, float would be free by default while events based would be constrained.

Exactly that was my point about typed arguments. string, float would be free by default while events based would be constrained.

Ok, so it's time to bring validation into the discussion. Because even "free" texts or numbers aren't truly free, e.g. they would be lowercase-only, non-empty, larger than zero, etc.

For the constrained ones we'd typically have the default validation that the value has to exist in the list of allowed values. Practically enum type.