Hi @ethicraul, nice to meet you!
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
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.