what I learned since asking:

- MessageChannels introduce an additional state so implementing is more complicated than plain ole' postMessage
- MessageChannel still need to be setup with a handshake over postMessage so you still need whatever origin checks you need there
- subsequent communication is private which sounds nice but I don't have a good grasp on when this would come in handy practically. something like an XSS attack that is also subscribing to window message events and stealing that info but hard to reason about especially since the initial setup still requires postMessage

ended up using MessageChannel and satisfied with the result

the MessagePort interface turned out to be an elegant way to avoid race conditions around loading + initialization since it has a queue built in

both sides can start send / receive messages when they are ready

Building @warpcast and @farcaster / dad / like to read, cook, ski, code

handshake:
- root origin sets up MessageChannels are can immediately start sending messages to them
- add message event listener on top level document looking for init message from wallet origin
- load wallet origin in iframe
- add message event listener on local document looking for init response with transferred ports
- post init message to root origin
- root origin transfers ports from message channels to wallet origin
- continue with initialization logic and when ready to start processing messages start the port

communication lifecycle is decoupled from iframe loading and initialization lifecycle

I assume this code will be open sourced with the rest of the client eventually?

if there's something specific you want to see DM me

appreciate it -- nothing immediate, but hopefully in the next ~month we'll kick off a web connect feature for Teams that will need this or postMessage