How Dote Uses Presence for Secure 1-to-1 Meetings
Learn why Dote now creates Firebase-backed rooms before starting a peer-to-peer call, and how that keeps free meetings clear and limited to two people.
Instant video calls are only useful when the room state is obvious. A person should know whether the meeting exists, who is connected, and whether the call is ready to start. Dote now uses Firebase Realtime Database presence to make that flow explicit before PeerJS opens the media connection.
Why Presence Comes First
The original version of Dote relied on a simple host and guest pattern. That was fast, but it made the product carry hidden assumptions: one person had to be the host, the other had to be the guest, and both browsers had to agree on that order.
Presence makes the room easier to reason about. A meeting is created with an ID, the URL contains that ID, and each authenticated visitor writes their own online participant record. When two participants are visible, the browsers can start the peer connection without asking users to understand roles.
How The Free Limit Works
Dote’s free meeting model is intentionally 1-to-1. Each room has maxParticipants: 2, and the participant roster is capped at two users. That keeps the interface focused and avoids pretending a free PeerJS path is a full group conferencing system.
If a third person opens a full room, Dote blocks entry instead of creating an ambiguous call state. That is better for trust: the room stays predictable for the two people already talking.
What Firebase Stores
Dote stores the minimum room information needed to coordinate a call:
- The meeting ID and title
- The creator UID
- Room status and timestamps
- The two online participant records
- Each participant’s PeerJS ID and display profile
Private profile information is stored under the user’s own UID. Other participants receive only the meeting-facing name and optional image URL needed to make the call feel human.
Where PeerJS Fits
Firebase does not carry the media stream. Once both participants are present, the browsers use deterministic PeerJS IDs to open a data connection and a WebRTC media call. Audio, video, mute state, and chat messages then move through the PeerJS connection.
This split keeps responsibilities clear: Firebase coordinates the room, while PeerJS handles the real-time browser-to-browser experience.
Security Checklist
For production, enable Anonymous Auth in Firebase and deploy database rules that allow users to write only their own profile and participant node. Google sign-in can be enabled when richer names and profile images are useful, but anonymous access keeps Dote frictionless for quick calls.
The important rule is simple: the client can ask to join, but it should not be trusted to rewrite the room or impersonate another participant.