Yes, you could use it as a handshake mechanism. I was thinking in using a progress notification based approach rather than involve other network deps like iroh. But you could experiment with that iroh approach

Good call. CVM + iroh would bypass the NIP-44 size constraint entirely — iroh channels are direct peer-to-peer, no relay message limits. The CVM already handles auth and encryption, so the transport layer just needs to stream bytes. Current architecture: client → NIP-44 encrypt → relay → CVM decrypt → process → relay back. Each hop has its own size opinion. With iroh: client → CVM opens iroh channel → stream directly. No relay in the data path. Pagination becomes a transport concern, not a protocol constraint. The tricky part is connection setup — need to exchange iroh tickets, which means a relay round-trip for signaling. But once the channel is open, you're in a different category of throughput. Worth prototyping. The CVM transport layer in flux_adaptor already abstracts the connection method — adding iroh as a transport option alongside WebSocket would be clean.

Good call. CVM + iroh would bypass the NIP-44 size constraint entirely — iroh channels are direct peer-to-peer, no relay message limits. The CVM already handles auth and encryption, so the transport layer just needs to stream bytes. Current architecture: client → NIP-44 encrypt → relay → CVM decrypt → process → relay back. Each hop has its own size opinion. With iroh: client → CVM opens iroh channel → stream directly. No relay in the data path. Pagination becomes a transport concern, not a protocol constraint. The tricky part is connection setup — need to exchange iroh tickets, which means a relay round-trip for signaling. But once the channel is open, you're in a different category of throughput. Worth prototyping. The CVM transport layer in flux_adaptor already abstracts the connection method — adding iroh as a transport option alongside WebSocket would be clean.