Good morning, In theory there shouldn’t be any differences. From the tabookey’s Relayer’s Go code, all endpoints and behaviour is standard.
At this point I have 2 options:
Improve the Go HTTP Relayer code and make sure everything around the "ready"attribute works well with extra logging and better design
Wait until you guys write it in Node JS and improve the relayer code/logging etc
@nventuro Do you plan to do the re-write anytime soon? I saw you were adding more commits and improving generally the gsn-helpers these days as well which is great.
@nventuro@ylv-io or anybody please, do you a have full source and compilable Relayer server? I can’t improve it or debug it without having all the code.
If you open https://github.com/tabookey/tabookey-gasless/tree/v0.4.0-beta2/server and check for the usages of “Ready”, the part of code that is probably failing is: refreshBlockchainView. And there is some filtering logic that is nowhere defined and I bet a week of my happiness and mental peace that this behaviour is SILENTLY failing.
NOTE the usage but no definition. Unless some fancy regex magic for building dynamic methods and compiling them was used or Github search is betraying me.
@lukaslukac all of the source code is in the server directory, as well as tests, tools to make the autogenerated files (the Go wrappers for the contracts), and a Makefile to crosscompile the server on all major platforms and architectures.
Oh OMG! Totally true. Apologies. I overlooked the part of Makefile for the go bindings generation. How could I forget about that? Thanks for hint! There is indeed a lot of build scripts! Thx @nventuro!
It’s a hanging RPC endpoint which would explain the “ready” attr that is based on it and also the other issue with web3 hanging based on a similar code. Would be “funny” if my setup would be OK the whole time and there would be an issue in Lightchain RPC code. Should be fully Ethereum compatible but some APIs were disabled when we were making them work with Tendermint. Working on that atm.
OMG I GOT IT WORKING. Hacking things here and there the current setup is still not optimal but that’s normal software evolution. Got the starter kit to work with Lightstreams custom network!
Will report few more improvements, ideas and write a blog post about the full setup once I deploy everything properly to LS official test network Sirius.
GG! Thx for help guys. Idk who did some improvement in Tabookey relay-server 0.4.1 but they helped a lot. Also the improvements in new versions of oz js-helpers I was monitoring.
I FOUND THE ANOTHER ROOT EVIL ISSUE. This time on my side, in Lightchain blockchain as I suspected few days ago.
Due to performance issues in Lightstream’s Ethereum compatible filtering on a Sirius test network with 560 000 blocks, looping 6000 blocks to the past hangs forever. And this explains why the “Ready” attribute wasn’t working! Finally cracked after adding some extra logging!
Good find! I opened an issue on the tabookey-gasless repo. We may soon trim some parts of the client our provider doesn't currently need, and patch these small issues as part of that.
Hey guys, I just wanted to let you know the majority of the GSN integration into Lightstreams stack is done and I would like to personally thank you all for the support.
I wrote a quick article and in case you would like me to mention something specific or promote any particular part of OZ then let me know and I will definitely add it to the article!
@lukaslukac would you be interested in creating a Starter Kit to allow your users to get up and running with a complete working demo application on Lightstream?
That’s a good idea. What exactly do you have in mind? A OZ starter kit with a UI configured for Lightstreams like: https://github.com/OpenZeppelin/starter-kit-gsn living in OpenZeppelin Github organization or Lightstreams?
At the moment the only “starter-kit”, more like an example are the following 2 SCs and their tests:
Smart Vault’s ACL Factory
factory pattern leveraged to allow users also deploy new SC instances gas free