[Withdrawn] State Channel mobile client

[dimitar.chain]

Proposal Status

Status: Inception
Last updated: 06.06.2020
Team: TBD
Planned Delivery: TBD

Value Proposition

Mobile client for State Channels that relies on a synced node with a FSM. Something resembling a wallet but for State Channels.

We had been talking for this for years now and made some demoes. The demoes themselves were valuable and provided insight on what should be changed or improved in the FSM. Based on this feedback I think now we can actually do it. Possibly the longest and deepest description can be seen here (note more than an year ago):

State of State Channel æpps. We need more!

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 a…

A short version would be that developing a mobile client for State Channels is hard. To make it worse - our current expectation is every service provider to build their own client. This makes it both expensive for them and trustful for their clients.

Proposal is to make a unified generic State Channel mobile client that can run different contracts.

Definition of Terms

I propose we make a TypeScript mobile progressive web app that opens one state channel and deploys a contract. This mobile client will handle all FSM events and will allow all functionality that is already there to be actually used:

• open a state channel with an arbitrary participant
• close a channel with a mutual agreement
• deposit more tokens to the channel
• withdraw tokens from the channel
• snapshot current channel state on-chain
• force progress a contract call on-chain
• transfer tokens to a participant off-chain
• import an arbitrary Sophia Contract with a UI corresponding to the contract’s ACI (this is the cool stuff, really)
• close a channel using the unhappy path
• reestablish a temporaryly closed connection to the other participant
• handling conflicts and race conditions
• have off-chain encrypted chat (because it is cool)

In order to make this safe, the app will also:

• keep keys for the participant
• persist the state of the channel locally (so if the node that provides the FSM dies, client can still reestablish)

In order to make the contract depoyment decentralized, we will implement a small website to provide two contracts with corresponding UIs.

Users will open a channel, drop a link to desired contract and thus install it in the channel. Then they can safely execute calls and close it. Then they could open another channel and install a different contract in it. The application will behave homogeniously with regards of the FSM.

This proposal will make writing State Channel applications as simple as writing Sophia Contracts and corresponding UI, both of which will be public. This will greatly lower the entry barrier for projects that want to use State Channels.

Status Quo

We have a few demoes, to the best of my understanding only one of which is supported. None of those came even close to this.

We expect any service provider that wants to use State Channels to implement all of the work described in an open and honest manner. If for example they decide to forget implementing the forced progress - users will end up in a trustfull scenario.

If we leave it to service providers to implement their own apps, we will end up in a messy situation where different actions are triggered differently and this will confuse users.

Required Work

If there is interest for this, I will assemble a team and will define the details.

Estimate

If there is interest for this, I will assemble a team and will define the details.

Known Limitations

There is a lot of work to be done, a great deal of which will revolve around handling communication from and to the FSM. This is a MVP and could be further extended in another proposal(s).

I want to make it clear that having a couple of opened State Channels in the mobile app will complicate it even further. This is not in the scope of this proposal.

State Channels support having as many contracts in their state as one needs. This will complicate the UX further more. This proposal is just for one contract in a single opened State Channel.

Regarding the webpage that hosts contracts - we want it to keep it simple. No upload, no edit, no nothing. It will be a set of static pages. If someone wants something else - they can host it themselves.

Although we will try making it pretty, design is not in the focus of this proposal. The State Channel UX is a problem all projects face. I don’t expect we solve it with this proposal.

Outlook

For developers:

• they will only have to write Sophia smart contract and UI for it. No work with SDK, no interaction with FSM
• this will greatly reduce their invested effort of time spent
• this will ease their learning curve

For users:

• they will get a homogenious State Channel experience
• they will get one app for their State Channels that behaves as expected

For the ecosystem:

• this will make State Channel addoption much easier (or even possible)

For me personally:

• I will be finally able to explain my mother what I am doing

[dimitar.chain]

This had been discussed more than once. Essentially every time people start asking how they’re supposed to use State Channels, conversation dies with this. Random examples from the forum:

Why we haven't seen any applications for state channels and oracles?

Responding about State Channels because I am really strongly opinionated about this. I envision basically 2 different use cases: B2B and B2C. The first one can be built right now and would allow companies to call contracts off-chain at blazingly fast speed. This includes all IoT cases as well. For this one could easily use either the Elixir or the JS SDKs. I personally would pick the Elixir one as it is much more battle tested. This sadly had not been marketed in any way and since no B2B use ca…

Any plan to implement state channel feature in base wallet?

Hi, is there any plan to implement state channel in base wallet? This will be a huge advantage when instant transaction is enabled between users/business.

It would also make the Hypermine project a breeze. Currently they have to grunt their way through documentation and SDKs. With this project at hand, they could simply write a contract and get the job done. I am not pinging them because they are not part of the internal sections of the forum. I think they could be a test subject if this project is required or not

[marco.chain]

love to see that proposal! this is definitely needed

[uwiger]

Sounds like a great idea

[dimitar.chain]

While it is no guarantee for SC adoption, I don’t see it happening without it

[lydia]

@dimitar.chain Thank you very much for your valuable Application. Please give an estimate of time per developer of your team.

[dimitar.chain]

Hi @lydia

I wanted to know if there was an interest from the Foundation. Now will proceed forming a team and making an estimate. Once I am done - I will write here.

[Fee.chain]

Hi，lydia.Many developers and users are very interested in the state channel, but keep their distance because of mystery. I hope there is a simple and easy-to-understand client that allows more people to understand the state channel.

[Janson]

Up to now, users and even developers don’t know what aeternity’s state channel is. I hope there are specific applications to verify the power of state channel. I hope more people know about the state channel and like it.

[nikitafuchs.chain]

import an arbitrary Sophia Contract with a UI corresponding to the contract’s ACI (this is the cool stuff, really)

There I can help with, as the AE Studio Editor has a functionality like this.

[dimitar.chain]

Thanks for the interest in the proposal. Sadly, due to limited availability, I will not be able to gather a team, nor I could work on this proposal. I mark it as withdrawn and I am closing this thread.

[YaniUnchained]

Sad, someone else maybe wants to take this proposal, build a team and make a new application at the foundation. Seemed that there is real interest to make state channels more accessible, which was the main purpose of the state channel demo(s).