docs: add message passing unification discussion specs #39
Conversation
|
|
||
| The payload is an opaque `bytes` value. The Extra Data encodes optional logic or metadata (such as low-level calls) that the underlying messaging protocol should process during delivery. | ||
|
|
||
| ### Hooks |
There was a problem hiding this comment.
The main question I want to discuss regarding hooks is how using a hook differs from having the sender just invoke these functions before sendMessage.
There was a problem hiding this comment.
As we covered on the last call, the gateway itself invokes the hook, so the hook knows it’s running in the exact context of the message being sent. That gives us real atomicity and keeps extensions permissionless.
| ```solidity | ||
| interface IMessageRecipient { | ||
| function receiveMessage( | ||
| bytes32 messageId, // Unique ID supplied by the destination gateway |
There was a problem hiding this comment.
@cjcobb23 wants to discuss bytes32 vs bytes for this parameter.
There was a problem hiding this comment.
Still open for discussion, from our perspective, bytes32 is cheaper and is what most tooling expects, so a protocol can still hash a string into a bytes32.
| ERC-7786 introduces attributes (key/value blobs interpreted by the gateway). Hooks fill the same niche but with two advantages: | ||
|
|
||
| 1. Arbitrary Logic: A hook is external contract logic that the message sender wants to execute. Hooks remove the limitation of relying solely on the selectors implemented by the Gateway, enabling developers to execute arbitrary functions the Gateway didn’t originally anticipate. | ||
| 2. No bloat for minimal gateways: A bare-bones gateway doesn’t need to parse or store attribute blobs. If a project wants richer behavior, it can deploy its own hook contract. |
There was a problem hiding this comment.
Note that a bare-bones gateway in current ERC-7786 doesn't need to handle attributes, it can return false in supportsAttributes and have require(attributes.length == 0) within sendMessage.
Opening this PR to consolidate part of the latest discussions around cross-chain messaging, and to continue discussing what a unified API could look like. This draft is also meant to spark collaboration on the most relevant contrasts we've encountered, especially the differentiation between attributes and hooks. This collaborative effort is open for discussion and contributions.