State channels are quite complex and there are a ton of race conditions to be handled. A new update can be triggered by both parties, it can be canceled, internet connection can drop, a malicious participant can try to close the channel with some older state and etc. Those can happen any time, in any sequence of events and this imposes a big software development challenge. The Aeternity node’s channels implementation already provides gracefully handling of almost all of the above and solutions are being prepared for the rest as we speak. That’s why at the moment a client is supposed to connect to one’s trusted node via WebSocket connection and when an event happens - the node notifies the client for it. All a client must do is to handle the events that are fed to it.
@Vlad currently if someone wants to build a state channel’s app, one must take care for:
- opening a channel - it is a set of events the node already handles but those must be handled client side
- closing a channel - it is a set of events the node already handles but those must be handled client side
- handling of all of the unexpected on-chain events like hey, Alice is closing the channel with some older state, do you want to do something about it?
- handling of all off-chain events: Alice proposes a ContractX to be added to your state channels’ state. Do you agree? .
- signing of both on-chain and off-chain transactions and handling of keys, wallets integration
- persisting the state locally on the device so if your trusted node suddenly dies - you can still reopen the channel using the latest state
All of those are a lot of work and must be implemented again and again for every new application. What is even worse is various application can implement this in a different manner. In order for me to be sure the application I am using is not cheating me, I must either read its code (esp. disputes related parts) or trust it. I find both approaches bad as none of them takes advantage of Aeternity’s state channels being homogeneous and predictable in their mechanics.
The real issue is we don’t have a generic client.
Something that is going around in State Channels’ world (not just AE) is a generic app that handles all you state channels for you in a predictable manner. This will build proper user experience and no surprises. This is something like the Holy Grail of State Channels. And we can do it.
What we need is an application that is both BaseApp and State Channels aware and can close the gap between those two. We already have the SDK that handles the State Channel’s events so we need just to close the gap. I think the hardest nut to crack here is the user experience.
My suggestion is we extend the BaseApp into a mobile application that handles all the functionality that is already there. Let’s make it state channels’ aware. Imagine the following: you have a single app that handles sending of on-chain transactions and state channels. All Aeternity in a single app, all channels, for all of your accounts.
You want to open a state channel with me? Just scan my code and your application will connect to your node, which will connect to mine, which will connect to me. All easy, all smooth, all transperant. Then there is a pop-up that prompts you on your device to sign the opening transaction. So do I. Then we get another prompt when our state channel opening transaction has enough confirmations so we can start doing off-chain interactions in a safe manner.
Let’s play chess off-chain 
We pick a game from a decentralized market and install it in the state channel with a single click. There is a prompt to sign and - voila - we can play chess off-chain now. Or bet on a certain Oracle’s responses.
Each off-chain state channel application can consist of a smart contract and one or more UIs. Although we do share the same contract - the chess that visualises on my phone can be different from the one on your phone and this is great actually. What is even better is an off-chain state channel developer will only write the Sophia smart contract and one or more user interfaces that call this contract’s functions. Just that. No state channels’ event handling, no key handling, no dispute handling. I think this will make it much easier to onboard and develop, while making off-chain applications much more secure and safe.
If I can make a metaphore: let’s build an iOS for state channels, let’s handle all the security issues, let’s handle all the race conditions and let Sophia developers do what they should - build on top of it.
Currently this is an idea that is growing inside my head for quite a while now, so I’d love to hear your thoughts about it.
Best,
Dimitar