Payment vs update

[leighmcculloch]

The state machine in the sdk/state package currently supports a payment.

That's okay because the sdk we are building is intended first for payment channels where participants make payments to each other. This is also convenient, we can make the state machine very safe for payments by adding logic in the state machine to prevent payments that don't make sense. For example, if A proposes that B pay A, the state machine can simply error and require payments to be initiated by the sender. This significantly increases their safety.

This decision may not be correct if we also plan for the channel sdk to support other types of agreements, like invoicing or exchanges. Invoicing are not particularly interesting, but exchanges are and may be very useful. A channel is particularly well suited to supporting exchanges.

When it comes time to add support for other types of agreements, like exchanges, to the sdk, we will need to add support for them all the way down to the state machine if the state machine supports payments explicitly. With such changes the state machine will support payments and exchanges as first class features and offer different levels of safety about them. Payments will be relatively safe and require little inspection by the user. Exchanges will require full inspection by the user, and the user won't be able to blindly give an exchange to the state machine for processing.

This is probably all fine and still the best approach because the sdk will primarily service payments and so it is better if the state machine is safer to use for payments.

However, it does raise the question: is the state machine taking on a responsibility it should not? If the state machine supported only update as a first class feature then the logic for safe payments and exchanges would exist in something else outside the state machine and the addition of any new type of agreement would make no changes to the state machine. The state machine would become less useful on its own for payments specifically, but more flexible for other use cases.

Given the state machine is intended first for payments I think what we're doing now is the appropriate call, but I'd like to hear from others.

We can always refactor the state machine later and extract the payments logic into some other type. I suspect if we tried to do that now that we wouldn't really know what that other thing should look like and it'd slow us down trying to figure that out. It'd also increase the complexity.