refactor!: accept any msg type via AccountAPI.sign_message [APE-1305]

[z80dev]

What I did

Refactor the definition of sign_message to accept Any. Signers implementing this class can raise when they receive a message type they can't handle.

Account plugins would each individual handle msg objects by type, including how they might display information from them for user feedback in terms of signing. This will improve UX because now we can display the text of a string message to sign (useful for displaying SIWE EIP-4361 authorizations), the complete object body and header for EIP-712 structured messages, and other future types of messages that might become necessary to support within Ape (EIP-4337?)

fixes: APE-1103

How I did it

Change type signature of sign_message function, and update implementors to match the new definition.

How to verify it

Run existing test suite

Checklist

• All changes are completed
• New test cases have been added
• Documentation has been updated

[linear]

APE-1103 Refactor `AccountAPI.sign_message` arguments

Currently, this function only accepts a SignableMessage type, which limits it's ability to be used in situations where more information is required (such as signing through eth_signTypedData RPC endpoint)

My proposal is to refactor to sign_message(self, msg: Any, **signer_options) -> MessageSignatureand have it raise if the particular signer is unable to handle the type of msg (which could be str, eip712.EIP712Message subclass, SignableMessage, or something else)

Account plugins would each individual handle msg objects by type, including how they might display information from them for user feedback in terms of signing. This will improve UX because now we can display the text of a string message to sign (useful for displaying SIWE EIP-4361 authorizations), the complete object body and header for EIP-712 structured messages, and other future types of messages that might become necessary to support within Ape (EIP-4337?)

This is driven by a specific need right now, as I've been trying to get an ape-frame plugin working, and this is currently a blocker for that to be fully implemented since sign_message must call out to frame via eth_signTypedData_v4

Rating 5 points because all account plugins will need to be updated to handle the new arguments

[linear]

APE-1305 "implement new sign_message fn accepting Any" (ApeWorX/ape #1614)

What I did

Refactor the definition of sign_message to accept Any. Signers implementing this class can raise when they receive a message type they can't handle.

Account plugins would each individual handle msg objects by type, including how they might display information from them for user feedback in terms of signing. This will improve UX because now we can display the text of a string message to sign (useful for displaying SIWE EIP-4361 authorizations), the complete object body and header for EIP-712 structured messages, and other future types of messages that might become necessary to support within Ape (EIP-4337?)

fixes: APE-1103

How I did it

Change type signature of sign_message function, and update implementors to match the new definition.

How to verify it

Run existing test suite

Checklist

• All changes are completed
• New test cases have been added
• Documentation has been updated

---

ApeWorX/ape #1614 by z80dev on GitHub

via LinearSync

[fubuloubu]

Changes look good to me, I'll let @antazoey give final approval (and see if she likes the warning log)

[linear]

APE-1305 "implement new sign_message fn accepting Any" (ApeWorX/ape #1614)

What I did

Refactor the definition of sign_message to accept Any. Signers implementing this class can raise when they receive a message type they can't handle.

Account plugins would each individual handle msg objects by type, including how they might display information from them for user feedback in terms of signing. This will improve UX because now we can display the text of a string message to sign (useful for displaying SIWE EIP-4361 authorizations), the complete object body and header for EIP-712 structured messages, and other future types of messages that might become necessary to support within Ape (EIP-4337?)

fixes: APE-1103

How I did it

Change type signature of sign_message function, and update implementors to match the new definition.

How to verify it

Run existing test suite

Checklist

• All changes are completed
• New test cases have been added
• Documentation has been updated

---

ApeWorX/ape #1614 by z80dev on GitHub

via LinearSync