Short answer: For a live property-management poll, give attendees captions when speech affects a decision they must make now; create a post-session transcript only when someone has a defined reason to inspect the spoken record later. The first is a short-lived viewing permission. The second is a durable access and retention decision. Do not treat the transcript as the default output of a caption stream.
| Need | Pick this when | Scope to decide first |
|---|---|---|
| Live captions | Attendees need to follow spoken poll instructions during the session | Who may receive text for this session, and for how long? |
| Post-session transcript | Authorized staff need to review what was said after the vote | Who may read the stored record, and when is it removed? |
| Both | Participants need immediate access and an approved record is necessary | Separate viewing authority from recording authority |
When do users need live captions instead of a post-session transcript?
Imagine a building meeting where the moderator reads a proposed maintenance schedule, then opens a poll. An attendee following the meeting needs the spoken question in time to vote. A staff member handling a later dispute may need the wording afterward. Those are different people, clocks, and permissions.
For captions, issue a session-bound viewer credential that can subscribe to the current text stream but cannot request historic text or enable recording. The server, not the client, decides which building session the credential names. Treat all text received from a browser as untrusted input; an attendee changing a session ID in a request must not gain another building's captions. Expire access at the end of the session and check authorization again on reconnect. Short-lived access is useful here precisely because a copied viewer credential should not become a path to an old meeting.
A transcript is a separate publication step. Define its audience, retention window, and correction process before persisting anything. Spoken remarks can include apartment numbers or names. That possibility changes the decision even if the caption transport works perfectly. In a meeting where residents must select one of 2 proposed maintenance dates, a transcript delivered tomorrow cannot give someone the question while voting today; conversely, captions that vanish at close cannot answer a later dispute about what the moderator said. Neither output substitutes for the other.
Check the token.
Pick live captions for an active vote
Show current speech alongside the poll, with speaker context where the application has it. Keep caption timing and poll state distinct: a late caption must not silently reopen a closed vote. The interface should make the poll's actual closing state authoritative, rather than deriving it from when a line of text arrives.
Consider the before and after. Before separation, one broad session token permits both receiving speech and fetching the eventual record. After separation, a viewer can follow the live question but cannot enumerate stored meetings. That's the important change. This design has a cost: separate scopes require separate authorization tests and a deliberate decision about which staff roles may publish a record. A team without the ability to maintain that review process should not enable transcript storage by default.
WebRTC is one standardized option for real-time communication between browsers, but transport choice does not establish application authorization; the WebRTC specification describes communication APIs, not the permission model for a property meeting. A text stream over another transport still needs the same per-session checks. Design the viewer state explicitly: connected, reconnecting, or captions unavailable. A missing caption is an accessibility failure to surface to the moderator, not a reason to pretend the poll text was delivered.
Pick a transcript for a reviewable record
A transcript helps only if readers can tell what it represents. Keep poll questions, vote state, and speech as separate records. A transcript of spoken words cannot prove when a ballot was accepted; the poll service's own events must answer that question. Likewise, captions may be partial or revised while speech is underway. If you publish a transcript, label its status and establish who can correct it.
This choice introduces storage and operational work: access reviews, deletion, export policy, and handling sensitive remarks. Measure those obligations before promising a downloadable record. If no one has authority or a concrete review task, skip persistence and keep only the live viewing path.
Implement the boundary once, then observe it
A minimal TypeScript sketch makes the server-side distinction hard to miss. The claims in this example are application-defined inputs to a verifier, not a particular vendor's token format. Verification must also check signature, expiry, and the session's current authorization rules before returning these claims.
type Claims = {
sessionId: string;
action: "captions:watch" | "transcript:read";
};
function authorize(
claims: Claims,
requestedSessionId: string,
requestedAction: Claims["action"]
): boolean {
return claims.sessionId === requestedSessionId &&
claims.action === requestedAction;
}
The function takes verified claims; it does not mint or validate credentials. Test denied cases as carefully as the allowed one: wrong building session, expired authorization, a watch-only token presented to a transcript reader, and reconnect after access is revoked. Log the decision category and session identifier under your data policy, but keep raw speech and credential values out of routine logs.
For operations, graph caption delivery delay, disconnects, and authorization denials separately from transcript publication and read failures. A rise in reconnects calls for transport investigation; an unexpected transcript read calls for an access investigation. Two alarms, two owners.
There is a real trade-off here.
The limitation of live captions is that they cannot serve as a verified voting audit trail or a reviewable record after the meeting. The limitation of a transcript is timing: a later record cannot help someone who needs the spoken question before the vote closes. Separating permissions does not make transcription accurate, and it cannot settle how long a meeting record should exist. Those are product, accessibility, and policy decisions for the people running the meeting. When a meeting requires legally authoritative minutes, use the organization's approved minutes and ballot process rather than treating generated speech text as evidence of vote acceptance. The useful rule is narrower: let attendees read what they need to act now, and grant access to a lasting account only after its purpose and readers are explicit.
References
- W3C, WebRTC 1.0 specification. Its browser communication APIs do not define this application's token scopes.
Top comments (0)