Are you planning on switching to sign_typed_data_v4 for the meta-tx signature? . Since your SDK is more general, the TypedData could represent the relayed call (method name, parameters and values). With proper method naming on the GSNRecipient side, that could be enough
Hey @ethicraul! Thanks for posting. As you say, using a signed typed data would definitely improve the user experience. However, that would require a full new deployment of the GSN, since the central RelayHub contract is who verifies the signatures, so we’d need to modify that contract, and spin up a new network altogether. It is quite an effort, and we at OpenZeppelin are not working on new features for the GSN at the moment, nor actively participating on the Metamask contest.
That said, the TabooKey team has moved development of their implementation of the GSN to the openeth-dev organization, and they are working on a new version - with support for EIP712 signed typed data implemented just two days ago!
My suggestion would be to reach out to @alex and team to see what their roadmap looks like, and when a V2 can be expected!
we at OpenZeppelin are not working on new features for the GSN at the moment
This is... very worrying to read for a project that has just integrated with GSN and launched in production.
Does this means OpenZeppelin GSN will be deprecated? Do we have to deploy new contracts that are RelayRecipient instead of GSNRelayRecipient?
How can we help?
We also integrated your network.js library, upgrade contracts and were studying switching from Truffle to oz-cli for compilation and tests.
I can't see any mention of those in your roadmap post,so I kindly ask to include your plans for supporting the rest of your suite of libraries, it will help a lot.
My suggestion would be to reach out to @alex and team
That said, the TabooKey team has moved development of their implementation of the GSN to the openeth-dev organization, and they are working on a new version - with support for EIP712 signed typed data implemented just two days ago !
First of all, I would like to reassure you that even if OpenZeppelin's implementation of GSN will not be further updated, current versions of both GSN implementations are stable and production-ready, and also we at Openeth are fully committed to maintain and move forward both the implementation and EIP-1613 standard.
Regarding your original question about using sign_typed_data_v4, this is indeed a major part of our roadmap for GSN 2.0, as well as our wider effort of better integration with MetaMask. We believe slight modifications to the MetaMask itself could be required to achieve the UI similar to the one of Maker's 'permit' function due to some solidity limitations, which I will elaborate in the issue you've opened.
There are other changes to the GSN architecture coming in the following months, but we will try to make the upgrade to the new version as painless as possible. I would advise you to proceed with your project using the current GSN v1.0 unless you can wait a couple of months.
Two major changes to anticipate in IRelayRecipient solidity interface are:
The 'acceptRelayedCall' will take a EIP-712 compatible struct as input, thus requiring ABIEncoderV2 activation.
preRelayedCall/postRelayedCall will be extracted to a separate interface, allowing (but not requiring) different contracts to handle access control/execution and gas fee computation.
I don't expect any breaking changes to the client code at this point.
Both network.js and GSNProvider are OpenZeppelin tools and I cannot guarantee they will be made compatible. Openeth will provide an adequate replacement if needed.
Sorry if I caused an alarm @ethicraul. There is nothing to be concerned about: we will keep providing support for our GSN tools, which correspond to the currently deployed network (V1). What we are not doing is implementing new features, as we are focusing on other tools at the moment - we will publish our other roadmaps soon, but the gist is that we will be working on frictionless upgrades as presented on this post at least until March.
Now, regarding GSN v2. OpenEth is leading the development of this new iteration, which will require breaking changes and the deployment of a new network (ie new Hub and potentially new relayers). Once these changes are solidified (pun not intended), we will evaluate integrating them into our tools and libraries.
At first glance and based on Alex's comments, the changes seem easy to implement (slightly different signature on recipient contracts, separation of interface, new signing methods on the client), so we should be able to support it; but we cannot commit to a concrete timeline until we have a full understanding of the scope of these changes.
To clarify, that roadmap is just for the OpenZeppelin Contracts library: our other tools, such as the CLI, Upgrades, and GSN libraries have their own independent roadmaps which will be published soon.
