Build a social audio and video spaces product

SpacesTek is a learning path for a social room product: people discover a space, join as listeners or speakers, request to speak, share media, and leave without losing the product state around the room. The three stages are useful for different reasons. Initial teaches the product shape, Final adds a real MediaSFU room behind a secure proxy, and Advanced shows how to own the room UI while keeping the SDK responsible for realtime media.

This is a product blueprint, not a copy/paste tutorial. Choose the SDK guide for your platform before writing the room component. A product interface can be ported between platforms; an SDK operation must still be confirmed in that platform's own package and guide.

Build this: compare Initial, Final, and Advanced in the Starter Projects catalog. View source: Initial, Final, or Advanced.

Choose the stage

Stage	What it teaches	MediaSFU room status	Start here
Initial	Profiles, spaces, browse/create/join screens, roles, and request-to-speak product state	Introductory application flow; its starter clients do not provide a maintained MediaSFU room integration	SpacesTek Initial
Final	Secure create/join, a custom room surface, local and remote media, screen-share placement, and remote audio mounting	Multi-framework room reference using the current ReactJS 4.3.0, Angular 2.3.1, React Native 2.4.0, Expo 2.5.0, and Flutter 2.3.0 guides	SpacesTek Final
Advanced	Headless rendering, custom media surfaces, camera/device controls, moderation, join approval, and request-to-speak flows	Production-shaped multi-framework reference; live media acceptance still belongs to the target platform and device	SpacesTek Advanced
Kotlin SpacesTek	Compose screens for a Spaces-like audio product	UI and application-flow reference; use the Android SDK guide for the maintained MediaSFU room integration	No standalone public repository; use the Android SDK guide

The package versions above are the versions covered by the current MediaSFU operation guides. A sample repository may use an older package range, so check the selected SDK's installation page before installing.

The SpacesTek Initial repository is the introductory product-flow reference. Its clients do not provide a maintained MediaSFU room integration, so use it for application state and journey design only.

The product journey

1. Discover and create a space

The application owns profiles, topics, scheduling, invitations, role labels, and the space directory. A host submits a create request to the application's backend. The backend authenticates the host, checks the product rules, and calls the MediaSFU room authority. The browser or mobile app receives only the room-scoped response it needs.

For a private local experiment, a deliberately restricted development setup can use a direct SDK helper. For a shared, distributed, or released application, put reusable credentials behind the secure backend proxy. This boundary is the same whether you use MediaSFU Cloud or your own running MediaSFU Open server.

2. Join as a listener or speaker

The application decides whether a person enters as a listener, speaker, panelist, co-host, or host. The backend must enforce that decision; a client label is not a permission. A listener can request to speak, while the host or moderator resolves the request and changes the product role. Final and Advanced demonstrate this application state in their space screens. The SDK room still owns the actual media transport and participant media events.

3. Publish and render media

Use the selected SDK's media controls for microphone, camera, and screen share. For a custom room surface, keep these rules consistent:

1. Show an active screen share as the primary surface.
2. Otherwise show an identified remote camera, then the local camera.
3. Keep other cameras in a rail or participant grid.
4. Mount every prepared remote-audio renderer independently of video pagination or primary-surface selection.
5. Mirror only a local camera preview. Contain and never mirror shared screens.

Final demonstrates the basic headless boundary. Advanced adds custom grids, direct media surfaces, device selection, and richer control surfaces. Neither repository turns these application choices into universal SDK behavior: use the package-specific media lifecycle guide for the exact symbols on your platform.

4. Moderate the room

The familiar SpacesTek controls are application decisions around the room:

• remove a participant from the current room;
• keep a participant from re-entering through an application-owned ban rule;
• mute or restrict a participant when the target SDK and room policy support it;
• admit, reject, promote, or demote a request-to-speak participant;
• assign host, co-host, moderator, speaker, panelist, or listener roles.

Removing a participant is a room action. A durable ban requires the backend to bind the ban to an authenticated account or another stable application identity and reject a later join; a display name alone is not a secure identity. Final and Advanced contain example product state for these controls, but your server must be the authority for production permissions.

5. Leave, preserve, or end

These are three different user actions:

• Leave as a participant: disconnect yourself while the room continues.
• Leave as host and preserve the room: disconnect the host while other participants and the room continue, so the host can rejoin. This is available only where the selected SDK exposes the explicit preserve-room option.
• End as host: perform the semantic room-end action and move everyone to a final ended state.

The current SDK default for host exit is endRoomOnHostExit: true where that option exists. Do not silently change it. See leave, end, and rejoin for platform-specific actions and limitations.

What each reference is for

Initial: learn the product shape

Initial is the right first reading when the room product is unfamiliar. It contains profile creation, a browse/create/join flow, scheduled spaces, listener and speaker state, request-to-speak queues, participant cards, and sample moderation state. Its backend is a sample data service, not a MediaSFU room proxy, and its screens illustrate the product journey rather than running a MediaSFU call.

Use Initial to decide what your users see and which application records you need. Move to Final when you are ready to connect a MediaSFU room.

Final: add the secure room boundary

Final connects the space journey to a server-side create/join adapter. Its React, Angular, React Native, Expo, and Flutter clients keep the room engine mounted, pass create/join through the backend, render a selected video surface, and mount remote audio separately. Start by creating a room, joining from a second participant, producing local media, rendering remote video and audio, sharing a screen, and leaving cleanly. Test that complete journey on the browser or device your application will ship.

Open the SpacesTek Final repository for the application sequence, then use the package-specific SDK guide for the actual integration.

Advanced: own the UI without owning the transport

Advanced keeps the MediaSFU room engine as the realtime boundary while the application renders its own participant cards, grids, controls, moderation surfaces, and request queues. The repository includes secure proxy adapters for the web, React Native, Expo, and Flutter paths and adds headless media surfaces, screen-share-first selection, remote-audio mounting, camera/device controls, join approval, moderation, and request-to-speak flows.

Run Advanced with two independent participants through the secure proxy. Verify audible remote audio, screen share, device switching, permission failures, reconnect, moderation, leave, and host end on every target platform; a successful build alone cannot confirm those user-visible behaviors.

Open the SpacesTek Advanced repository and the headless guide before replacing the packaged room UI.

Kotlin SpacesTek: a product mock-up, not the Android SDK path

The Kotlin folder is useful for Compose information architecture: live and upcoming spaces, topic discovery, participant roles, listener counts, a raise hand action, and a room control bar. Its current Gradle file comments out the MediaSFU SDK dependency and declares the lower-level mediasoup-client transport instead. No MediaSFU room create/join, participant projection, remote-audio renderer, screen-share, host-end, or teardown claim should be copied from this app.

For native Android rooms, start with the Android SDK guide and the Kotlin room operations. For a Compose product shell, reuse the journey and role model here, then bind each screen to the Android SDK's documented public symbols.

Operations and runtime contracts

This pattern touches the following user operations. Their availability and validation are package-specific; the links open the practical guides rather than asking you to infer a platform contract from this blueprint.

Operation	Identifier	Practical guide
Secure room creation	room.create.secure	Secure backend proxy
Join a room	room.join	Headless room guide
List participants	participant.list	Media lifecycle
Readiness, production, and consumption	media.readiness, media.produce, media.consume	Media lifecycle
Screen sharing	screen_share.start_stop	Media lifecycle
Leave or end	participant.leave, host.leave_preserve_room, host.end	Leave, end, and rejoin

The implementation also relies on these room-runtime rules:

• Read the latest room snapshot without triggering updates during rendering.
• Ignore late transport responses safely after the user has left.
• Keep orientation, media, controls, and sidebars inside the same measured room container.
• Put an active screen share first and keep every prepared remote-audio player mounted even when its participant is not visible.
• Preserve the host-leave default, and reuse a retry key only for the exact same create or join request.
• Treat MediaSFU Cloud as the managed service and MediaSFU Open as the media server your team runs.

See headless room ownership, embedded room layout, and leave, end, and rejoin for the implementation details.

A practical release checklist

Before shipping a SpacesTek-style room:

• run the selected SDK's type, build, and focused tests;
• create through your authenticated backend and join from a second independent participant;
• verify microphone, camera, screen share, remote audio, camera selection, and permission-denial recovery on every target platform;
• exercise listener, speaker, moderator, and host paths with server-enforced authorization;
• verify participant leave, host preserve-room (if supported), host end, reconnect, and teardown;
• keep reusable credentials, room identifiers, invitations, and private logs out of clients, screenshots, and documentation;
• confirm that any recording, translation, HLS, telephony, or AI feature has its own backend ownership, consent, retention, and cleanup design.

Related guides: SDK packages, build styles, embedded room layout, and recovery and media controls.