eth_signTypedData, which is only supported by Metamask. The python client works because it does the signing locally (i.e. it opens the private key by itself). The TS client library rely on the eth node (e.g. Geth, Metamask) to do the signing, and geth doesn't support it directly
testfolder for the microraiden js/ts client library), or wait until last eip712 version is implemented on major clients and we update our implementation (which we plan to do as soon as metamask, geth and parity implements the accepted draft)
eth_signTypedDataformat proposed by Metamask, since the webUI client was the only one which didn't have much choice. As this early signature format isn't supported directly by geth, and being deprecated in Metamask, you may either wait for the final draft to be implemented in the clients, or right now follow the python implementations, open the key by yourself and implement the signature method by yourself (as the link above does for tests/ganache-cli)
nodeenvironment, and to achieve it, you need only to implement private key opening and local signing with
eth_signTypedDataMetamask early draft, as I pointed is already done/injected in the tests (you need only to do the same with actual keys/environment). The echo node has nothing to do with client, but with server. If you want to implement it in TS, then it'd need to be done from scratch, using the python server files as base for the algorithm. The echo server is actually a tiny data logic surrounded by the µRaiden
flask-restapidecorators and classes, so you'd need to implement it in TS (probably as an
expressmiddleware), and then it can be used on express endpoints, e.g. an endpoint which implements the echo node logic (basically, give back some request parameter/data upon payment, kinda useless, but good for testing)
confirmPaymentsets the next balance proof as the current one, and
setChannelthen persists it in localStorage (if present). If you're on
node, you may need to provide a
localStorage-compliant object to store the proofs. The webUI demo does not do this, instead it loads the balance proof that comes in the cookies for the next server response (the server sends it whenever it detects a valid/signed but outdated proof, e.g. when you load from blockchain, you sign a
0token balance proof, which will validate yourself with the server and trigger it into sending you your latest balance proof), validating it with
verifyProofand setting the up-to-date channel state locally. That should be the balance you're seeing when you load the channel with the the TS library.
localStorageor alike, or 2. sign a zero-proof, load latest from server,
verifyProofit and proceed from there.
cooperativeCloseif the server is available, by requiring a closing signature which states it agrees on a given paid amount, and acknowledges the channel isn't valid and won't accept payments in it anymore; 2. if the server isn't available anymore, the client then can do an
uncooperativeClose, presenting some balance proof on-chain, which will start a settle timeout, when the server (which is required to keep watching the blockchain) can challenge with its latest BP, or lose the already paid tokens if offline, but not locking forever the user's tokens
incrementBalanceAndSign: you need to "persist" this signature locally in your client, through
confirmPaymentor simply validate server response on next request, which should also contain the payment info you did (so, it's persisted on the server and validated on the client). Everything else seems to be in place
localStorageinstance (there's several implementations, e.g.) on the global context of your client to allow it to save and restore the channel info. When doing this, you shouldn't use
loadChannelFromBlockchain, but instead
loadStoredChannelat the startup of your app.
loadChannelFromBlockchain, which will load a
0-balance proof, request the resource to the server, and when the server detects it isn't enough (because its zero), it'll send your last BP, and then you
verifyProofit, and then your client channel will be properly initialized. That's what webUI client does, to avoid relying on localStorage, which may get cleaned
main.jsfile for the webUI, it contains a nice walkthrough of the steps needed
loadChannelFromBlockchainwill do the
signof the 0-balance proof, no need to
verifyProofshouldn't be run on the proof returned by
incrmenetBalanceAndSign, but on the one composed by data returned by the server. You said you did read main.js, but I'd ask you to give a closer look
@PeHo89 Conceptually, it's correct. You're not getting the implementation details and the constraints on web dapps: you can't be sure you'll always have the information available, as browser storage comes and goes easily (clear cache, opening it in a private tab, another device, etc).
So, I'll walk you through the default case, assuming you can trust the local storage (the place where your client will save the channel data, as it can't put it on the blockchain): 1. open a channel, or
loadStoredChannel from localStorage or a json file, wherever you saved it, 2.
incrementBalanceAndSign, 3. set headers/cookies, redo request, 4.
channel.next_proof once you're sure you got the resource you paid for, it'll save back the data to localStorage for the next run, 5. repeat from 2 as many times as you want, 5. close the channel once you don't intend to make other off-chain payments on it
That was the "happy" case.
But what happens if you don't have
localStorage (as you don't in your node instance)? You have 2 sources for each part of the channel info: 1. the blockchain, so you know the channel details, but outdated (without balance proofs, i.e. balance=0), 2. the server, as it also stores your last payment data, which you where supposed to persist but didn't, but to get it to sent it for you, you need to "authorize" with it, through an outdated balance (even if it's a zero-balance proof, the initial/pristine/fromBlockchain one). So you don't need the server for incrementing the balance, but if you didn't persist the data with localStorage or any other mean, you need to beg the server to update you with what it knows about you. This workflow replaces the
confirmPayment (as there's nowhere to store it) with
loadChannelFromBlockchain (which will give you the 0-balance channel) + redoing the request to get the data from the server, and
verifyProof it to be sure you're not being fooled into signing a higher amount than you should