docs: add message passing unification discussion specs#39
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.
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.
2 participants
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.