The owner of a broadcast channel sends in a webxdc app.
The webxdc as ran by the owner (preferred) or a separate bot would send in xdc updates to the broadcast channel for members to consume similarly to how they can already send in messages.
As the channel is receive-only as seen by subscribers, their webxdc app instance can’t send an update back. However, they can already reply in private to messages on the channel. The webxdc app that they ran could similarly post the update payload as a private response, to be processed by the webxdc ran by the channel owner (preferred) or a bot that collects this.
It is then up to the channel owner what to do with these updates: keep them hidden from others, aggregate them, or forward them back to the channel after moderation (checking business rules, mitigate cheating in games, etc.).
The existing submission API could also be reused for this use case when a webxdc instance detects that a subscriber is running it in a broadcast group. The existing API for reception could similarly be reused to process such updates received in private when the webxdc instance detects that the owner is running it in their broadcast group.
I’ve linked to some existing topics and posts that detail possible use cases in the end: polls with private votes, moderated social networking forums and groups, simulating limited reactions by subscribers and the dozens enumerated further. If you still find this insufficient, we’re open to further ideas!