We cannot directly interact with a world inside a Portal currently, because of the way iframe event handling works.
We could facilitate it via the outer shell [⇒ Meta Shell] which is able to forward messages between iframes. At the moment we keep this "meta" protocol to the absolutely necessary minimum – pretty much the only thing sent from the upper frame to a lower frame is the camera transform. Plus when entering a portal, the avatar data gets transmitted to the new world. discord
Until you enter the world you're a passive observer. To interact you'll have to actively enter the world. Note though that that's mostly an implementation choice: the underlying Croquet session for that world is activated as soon as the portal is opened.
From Croquet's POV there's no difference between actively and passively joining (though we would be able to do some optimizations down the road if that distinction was made known to the system).
Similarly with messaging between iframes via the shell: by default we will keep that to a minimum. If worlds were volunteering too much information by default that would create privacy issues, and if the messages they were accepting would be too generic that would open big security holes (worst case scenario would be that one frame could get another frame to execute some arbitrary code, which would completely obliterate the browser's iframe sandboxing guarantees).
Your own source code however will be able to define what messages get sent and processed, the shell should be an impartial message broker, just like our reflectors are impartial. So you could define whatever messaging you need between your own worlds, including implementing "action at a distance." But the base system should be as secure and privacy-conscious as possible, by default. discord
[…] when you walk to a different server it gets a "canonical" argument but the shell still runs on the original server. discord
~
⇒ iframe
"iframe event handling". duckduckgo , google
* Handling iFrame event in the parent web page. stackoverflow