Skip to main content
HashDrop’s video conferencing feature is built on LiveKit, an open-source WebRTC SFU (Selective Forwarding Unit) platform. Rather than establishing a full mesh of peer-to-peer connections between every participant, LiveKit routes media through a central server that selectively forwards streams — keeping bandwidth and CPU usage low even as participant counts grow.

​
What LiveKit provides

  • Room management: named rooms that participants join using short-lived tokens
  • Participant tokens: JWT-based credentials scoped to a specific room and identity
  • SFU architecture: a single media server receives each participant’s stream and forwards it selectively, avoiding the O(n²) bandwidth cost of a pure mesh
  • Cross-platform SDKs: consistent APIs for web (React), iOS, and Android

​
How HashDrop uses LiveKit

HashDrop integrates LiveKit at three layers:

​
Server-side: Next.js API routes

The livekit-server-sdk is used inside Next.js API routes to generate participant tokens and manage room state. No media passes through these routes — they only handle control plane operations.

​
Web frontend: React components

The @livekit/components-react package provides pre-built React components (<LiveKitRoom>, <VideoConference>, participant tiles) that connect directly to the LiveKit server. The useConferenceLogic hook attaches to RoomEvent listeners for connected, disconnected, participant joined/left, and data channel messages (chat, file transfer, join requests).

​
Mobile app: React Native SDK

The @livekit/react-native package mirrors the web SDK’s API for Expo-based iOS and Android builds, providing the same room connection and media publishing capabilities with native camera and microphone handling.

​
Conference API endpoints

HashDrop’s Next.js backend exposes six conference API routes:
MethodPathDescription
POST/api/conference/createCreate a new LiveKit room and return a host token.
POST/api/conference/joinGenerate a participant token for an existing room.
POST/api/conference/generate-codeGenerate a shareable conference code for the room.
POST/api/conference/admitGrant publish permissions to a participant in the waiting room.
POST/api/conference/denyRemove a waiting participant from the room.
GET/api/conference/waitingReturn the list of participants currently in the waiting room.

​
Room lifecycle

  1. Create: the host calls /api/conference/create, receiving a room name and a host token. The host’s client connects to LiveKit with full publish permissions and immediately starts the call.
  2. Share code: /api/conference/generate-code produces a human-readable code that other participants use to find the room.
  3. Join: participants call /api/conference/join with the conference code. If a waiting room is configured, their token is issued with canPublish: false.
  4. Waiting room: participants in the waiting room send a join-request data message to the host every 5 seconds. The host polls /api/conference/waiting every 2 seconds as a fallback in case the data message is missed.
  5. Admit or deny: the host calls /api/conference/admit (which updates LiveKit permissions to allow publishing) or /api/conference/deny (which removes the participant). The admitted participant detects the permission change via ParticipantEvent.ParticipantPermissionsChanged and begins publishing camera and microphone tracks.
  6. End: when the host disconnects or the room is deleted, remaining participants receive DisconnectReason.ROOM_DELETED and are returned to the lobby.
Connecting to a LiveKit server requires LIVEKIT_URL, LIVEKIT_API_KEY, and LIVEKIT_API_SECRET environment variables to be set in your deployment. Without these, token generation will fail and video conferences cannot be started. See Environment variables for the full list of required configuration.

Environment variables

Configure LiveKit server credentials and other required environment variables.

Build docs developers (and LLMs) love

Get started for freeTalk to us