Admin dashboard

Manage accounts, monitor live calls, and check outbound email — all served from lace.dev-road.sa, separate from the calling app.

Accounts
0
Pending activation
0
Live rooms
0

Newly registered accounts wait here for activation before they can sign in.

Live rooms the signaling server is relaying right now — real data, not a mockup.

Verification emails go out through this SMTP account.

SMTP settings
Verification email template

Sent when someone registers. Use {{displayName}} and {{link}} as placeholders — {{link}} must stay somewhere in the body.

Password rules apply the next time someone registers; login rules apply to sessions and sign-in attempts from now on.

Password policy
Login policy
Partner pinning policy

Choose the default LACE partner-pinning mode for admins and users, then decide whether users may override it locally.

Technical detail about the handshake LACE Meet runs — for admin reference; none of this is shown to end users.

Cipher suite
LACE-8.1-web · X25519 + Ed25519 + HKDF-SHA256 + AES-256-GCM
Security properties
Mutual authentication Forward secrecy Certificate-free Blind relay Replay protection
How a call is protected

Every property below maps to a real, documented step in the LACE handshake — not a marketing claim.

Pinned identities, not certificates
Verify a safety number once. Every session after that accepts only that pinned key — no certificate authority involved.
A fresh key for every call
An ephemeral X25519 exchange plus a three-phase HKDF schedule derives session keys that exist only for this call — then the ephemeral secret is deleted.
Encrypted before it leaves the device
Audio and video frames are sealed with AES-256-GCM in the browser. Relay servers forward ciphertext — they cannot decrypt what they carry.
Explicit proof, not blind trust
Both sides compute an HMAC key-confirmation value and verify it before a single frame of media is accepted.
Transport & signaling

LACE Meet runs the actual LACE handshake (X25519 + layered Ed25519 + three-phase HKDF + AES-256-GCM) between browser tabs over WebSocket, then negotiates real WebRTC audio/video signaled over that same encrypted channel. STUN only — no TURN relay, so calls need a directly reachable network path.