Build Participants and Collaboration with Shared Core

Use mediasfu-shared@1.1.0 when your framework package or custom renderer needs the low-level participant and collaboration functions without a supplied UI. This package does not render buttons, modals, lists, consent screens, or recovery messages. Your application must build and test them.

Complete the shared-core room lifecycle first. Keep account credentials, room creation, and product authority on your backend.

Bind the public functions once

Keep the functions behind one app-owned controller that always receives current room options:

import {
  handleCreatePoll,
  handleEndPoll,
  handleStartBreakout,
  handleStartWhiteboard,
  handleStopBreakout,
  handleStopWhiteboard,
  handleVotePoll,
  muteParticipants,
  removeParticipants,
  respondToRequests,
  respondToWaiting,
  sendMessage,
  startRecording,
  stopRecording,
  updatePanelists,
  updateParticipantPermission,
  updatePermissionConfig,
} from 'mediasfu-shared';

export const roomActions = {
  respondToWaiting,
  respondToRequests,
  muteParticipants,
  removeParticipants,
  updatePanelists,
  updateParticipantPermission,
  updatePermissionConfig,
  sendMessage,
  handleCreatePoll,
  handleVotePoll,
  handleEndPoll,
  handleStartBreakout,
  handleStopBreakout,
  handleStartWhiteboard,
  handleStopWhiteboard,
  startRecording,
  stopRecording,
};

Do not deep-import an internal file. Do not invent missing fields or reuse an options object from an earlier room. The functions coordinate through the current socket and room state supplied in their public options.

Build the participant experience

Your UI must show the current participant, waiting, and request state; the current user's role; which action is pending; and the result confirmed by the room.

Action	Observable success	Recovery
Admit or reject	The person leaves waiting and joins or receives rejection.	Keep the item pending until current room state changes.
Approve or deny request	The request closes and the affected permission or response appears.	Restore the current request after authority or connection failure.
Mute, restrict, or remove	The affected participant and remaining clients receive the state.	Never update only a local participant list.
Assign panelist or role	The target's role and available controls change.	Keep the previous role if the room does not confirm it.
Change permission	The target control follows the individual or room policy.	Restore only the failed setting and explain lost authority.

Disable authority actions while disconnected or while a previous action for the same target is pending. Ask for confirmation before removal or a broad permission change. Keep ordinary leave, removal, and host-ended meeting states different in the UI.

Build messages and polls

For sendMessage, display the intended room or direct recipient beside the send control. Keep unsent drafts according to your privacy policy. Show success only after current message state includes the message.

For polls, collect a valid question and choices, disable duplicate submission, and use handleCreatePoll, handleVotePoll, and handleEndPoll. Wait for the current poll update after each action. A reconnect must load the existing poll, not repeat the action.

Build breakouts and whiteboard

Before handleStartBreakout, show every assignment and any unassigned person. After start, show each participant's destination. Use handleStopBreakout before clearing assignment drafts. Reload current breakout state after a reconnect.

Before handleStartWhiteboard, show who may draw and what will be shared. A local canvas is not proof of a shared board; verify changes from a second participant. Use handleStopWhiteboard before discarding local tools or exports.

Before startRecording, explain what will be captured and collect the consent your product requires. Show recording as active only after the room confirms it. Use stopRecording, wait for the stopped state, and apply your backend's retention, access, export, and deletion policy. Shared core does not supply those product-policy screens or storage controls.

Reconnect and cleanup

After reconnect, reload participant, request, message, poll, breakout, whiteboard, and recording state before enabling actions. Never replay an interrupted authority or collaboration action automatically.

On leave, removal, or meeting end, clear app-owned selections, pending actions, drafts, timers, temporary exports, listeners, and room authority. Stop app-owned media and detach renderers. Follow backend cleanup for the room and any temporary grants.

Release checklist

Test host, co-host or panelist, and participant roles separately.
Admit, reject, approve, deny, mute, remove, and reassign with two clients.
Send room and direct messages to only the intended recipients.
Create, vote, and end a poll without duplicate submission.
Start and stop breakouts; confirm all destinations.
Start, use, and stop a whiteboard with a second participant.
Start and stop recording with consent and retention behavior visible.
Disconnect during every pending action and confirm it is not replayed.
Verify UI, listeners, drafts, media, and authority clear after exit.

Build and test your application, then run this checklist with its real framework renderer and the devices or browsers used by your product.

Bind the public functions once​

Build the participant experience​

Build messages and polls​

Build breakouts and whiteboard​

Build recording consent and lifecycle​

Reconnect and cleanup​

Release checklist​