The attendee watches the stream of the event they were invited to and takes part in its interaction with messages and likes of their own — BECAUSE the audience has to participate without ever gaining a view on the moderation or on the personal data of other attendees.

The presenter receives the curated questions on stage and records their processing, seeing nothing else of the interaction — BECAUSE the person on air has to be shielded from the raw audience input.

The administrator provisions the events and the streaming providers through the configuration of the software and, as the permanent bootstrap identity, enters every event without an access list entry and edits everything in it — BECAUSE the operation of the platform has to be reproducible from configuration and recoverable by one role that depends on no event-specific grant.

“I just want to watch the town hall and ask my question without jumping through hoops.”

“I keep the Q&A funnel clean and feed the presenter only questions which truly matter.”

“Setting up an event and getting the access URLs back to the Event Registration System has to be quick and repeatable.”

The system MUST authenticate participants via their email address before showing the video stream or, at minimum, before allowing participation in questions and chat, re-checking on every access that the event still lists the user even when the user is already authenticated — BECAUSE access must be restricted to invited participants to minimize foreign viewers

The system MUST let attendees submit questions as a dedicated feedback channel feeding the Q&A rounds — BECAUSE structured audience questions are a core interaction the event format depends on

The system MUST let attendees like questions and chat messages and undo the like — BECAUSE liking surfaces the most relevant audience input for moderators and presenters

The system MUST display an attendee’s name on messages as full “Firstname Lastname”, first name only, or anonymous per event configuration, always exposing the email address (at least on hover) and optionally deriving the name from the email if none is given — BECAUSE events differ in how much attendee identity should be revealed

The system COULD perform configurable client-side sentiment analysis that checks attendee input before it is sent and may prevent improper submissions — BECAUSE filtering at the source reduces server moderation load and discourages misconduct

The system SHOULD let attendees edit and delete their own chat and question messages, mark edited messages for others, and re-run moderation on edits where required — BECAUSE attendees must correct mistakes without bypassing moderation

The system MUST support optional moderation in which moderators reject, approve, or forward attendee input, with messages held pending until approved when moderation is enabled — BECAUSE organizers need control over what becomes publicly visible

The system SHOULD let moderators reply to an attendee’s input, including non-visible direct messages — BECAUSE moderators need to clarify details or provide support privately

After an event finishes, the system MUST let managers export all attendee inputs including at least timestamp, state, number of likes, and message text — BECAUSE organizers need a durable record of audience interaction

The system SHOULD let moderators filter messages and manually order forwarded questions — BECAUSE moderators need a clear overview and a defined order for the presenter to ask questions

The system MUST be accessible from any reasonably recent web browser without installation — BECAUSE attendees use both managed and unmanaged devices with no common client software

The system SHOULD support an event URL that also carries the user email (&user=<email>), making the email read-only in the login dialog — BECAUSE pre-filling the identity streamlines the attendee login

The system SHOULD support a &resource=<resource> URL parameter that selects a specific event resource on access — BECAUSE attendees reloading the page must return to the same stream or static resource

The system MUST require event attendees to give explicit consent before participating under defined conditions, in addition to prior platform consent — BECAUSE consent is both a legal safeguard and a psychological hurdle against prohibited stream sharing

The system MUST allow multiple streaming providers to be configured per event — BECAUSE a configured fallback is required to recover from provider problems even during a running event

The system MUST import an Excel sheet of the Event Registration System to populate an event’s access list and generate authorization tokens, avoiding duplicate invitations on repeated imports — BECAUSE events are provisioned from the Event Registration System

The system SHOULD export an event with its related entities to a serialized format such as YAML and re-import it — BECAUSE this eases development, demonstration, and creation of recurring production events

The system SHOULD record login-challenge statistics including issued, sent, and used authorization tokens — BECAUSE operators need visibility into the authentication flow for diagnosis

The system SHOULD record viewer statistics including country, browser, device, and viewport, using country to select the default application language on first use — BECAUSE audience composition informs both reporting and localization

The system MUST propagate event configuration changes directly to all connected participants — BECAUSE toggles such as enabling chat must take effect for the live audience without a reload

The system COULD provide real-time multiple-choice questions answered by attendees — BECAUSE polls add interaction during the event

The system SHOULD let an attendee switch the display and content language between German and English at any time from the header, applying the change immediately — BECAUSE attendees expect to read the interface and translated messages in their preferred one of the two supported languages

When an attendee deletes a message, the system SHOULD retain its position in the stream and show a “This message was deleted” placeholder instead of removing it — BECAUSE preserving the gap keeps the surrounding conversation coherent for readers

The system MUST support between 2500 and 10000 attendees connected to a single event at the same time — BECAUSE msg Filmstudio video productions must reach an audience of this size simultaneously