-
Notifications
You must be signed in to change notification settings - Fork 129
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow signed addKey
/addService
return type for later submission by other agent
#1373
Comments
Building on the above, the amended type TxnParams = [
attrName: string,
attrValue: string,
ttl: number,
signature: { sigV: number; sigR: string; sigS: string },
options: Record<string, any>,
]; In the introduced async didManagerSubmitTransaction(args: TxnParams, context: IAgentContext<IKeyManager>): Promise<unknown>; This method ( async didManagerSubmitTransaction(args: TxnParams, context: IAgentContext<IKeyManager>): Promise<any> {
// this method invokes a new provider method, which means that the calling agent calls `metaEthrDid.setAttributeSigned`
// with the provided txnParams (that were returned from the agent call in the first invocation within the MM Snap.
return provider.submitTransaction(args, context); // additional function made available on `did-ethr-provider`
} |
Is your feature request related to a problem? Please describe.
We need to invoke the below methods (using
ethr-did-provider
) which result in writes to the network:didManagerAddKey
(specificallyX25519
andEd25519
key types); and,didManagerAddService
(e.g. did-comm endpoint).As these calls invoke
eth_sendTransaction
which are listed asBLOCKED_RPC_METHODS
within MetaMask Snaps (more information here) the calls to these methods fail (see bottom of issue for error example).Describe the solution you'd like
I am open to suggestions on how best to approach this issue. One approach would be to allow an option/flag that would not submit the transaction to the network, but rather return the prepared (signed) transaction for submission in another context (i.e. via a Veramo agent instantiated in the DApp invoking). The addKey method looks like the below (did-ethr):
The returned (prepared and signed but not submitted) return type would look something like the below:
Describe alternatives you've considered
The approach that I have outlined above would necessitate the implementation of a new function (e.g.
submitAddKey
) so I am keen to hear other approaches.Additional context
Any method that invokes the
eth_sendTransaction
is going to result in this issue with errors corresponding broadly to the below example:The text was updated successfully, but these errors were encountered: