Payment Client

[ggwpez]

Location  New package, maybe [client/simple], [client/payment] or [payment/client].

Description 
The Payment Client API could look like this:

Compared to go-perun, the proposed API is synchronous and lets the user write linear programs without confusing callback magic.
I think this is important for making it more understandable.
In detail:

• HandleProposal is replaced by Client.Proposals() <-chan ChannelProposal from which the user can read the proposals that were sent to him.
• HandleUpdate is replaced by Channel.ReceivedPayments() <- chan amount from which the user can read the payments that he received.
• HandleNewChannel is removed. Its functionality is replaced by Client.Restore, Client.ProposeChannel and ChannelProposal.Accept.
• HandleAdjudicatorEvent is removed. Adjudicator events will be handled by the Client internally.

The callback version would look like this:

Context  We want to make go-perun easier to use for new developers.
This approach minimizes and simplifies the API at the cost of its versatility.
It would allow developers to create two-party-single-asset-payment-ledger channels.

Open questions:

• Do you like it 😄 ?
• Sub-Channels Y/N?
• Should the asset be fixed to ETH? (Allowing ERC20 would complicate the Bals struct)
• Do we need Payment requests?

Testing  A End-to-End test à la HappyAliceBobTest would be great.

[matthiasgeihs]

Do you like it 😄 ?
Yes.

Sub-Channels Y/N?
At first, no.

Should the asset be fixed to ETH? (Allowing ERC20 would complicate the Bals struct)
It would be nice if we can support ERC20 as well. Maybe we can wrap the Bals struct and make it easier to use?

Do we need Payment requests?
What do you mean by that?

I think you can go ahead with implementing the proposal. One requirement from my side would be that this requires minimal or at best no changes to the other packages. We should also have in mind that maintaining this payment client should not impose a lot of overhead when making changes to the rest of the framework.

[matthiasgeihs]

I think we should consider making this payment client available in a package separate from the core. What do you think?

[ggwpez]

Do we need Payment requests?
What do you mean by that?

If Alice wants to request balances from Bob, she would send Bob a transaction which increases her balance.
Bob could then decide whether he wants to accept this payment request by signing it or not.

[ggwpez]

I think we should consider making this payment client available in a package separate from the core. What do you think?

Yes we could do that but it would make it harder to maintain.

[matthiasgeihs]

We can leave payment requests for later.

Placing it in a separate repo would make that repo harder to maintain, but the core easier to maintain. I leave it up to you.

[matthiasgeihs]

Since you started implementing in another repo, I close the issue here.