Alexei Rojas Quiroga
← All projects

Personal project

CameraDesk

Desktop viewer for a consumer camera cloud, via a signaling and WebRTC proxy

Status
Prototype
Role
Solo: protocol analysis, Node proxy, web viewer, MAUI client

Architecture

  • Reconstructed vendor protocol
  • Hand-built TLS WebSocket relay
  • WebRTC live video
  • Web and desktop clients

The page logs in and wakes the camera through the Express layer, gets a ticket from the vendor API, negotiates over the relayed signaling socket, then receives media from the camera.

Architecture · 6 nodes · 1 flows
WHAT I BUILTHTML · WebRTCWeb viewerBrowser live view withRTCPeerConnectionExpress 5Control APILogin, status, control,ticketNode · TLS Web…Signaling relayRelays signaling framesHTTPSVendor cloud APIAccount, device, WebRTCticketWebSocketVendor signalingWebRTC session setupWebRTCCameraStreams live media1login, OTP, wake-up, ticket,status, control23456
  • Service / compute
  • Client
  • External system
  • Synchronous
  • Async / loop
Scroll sideways to see the full diagram

How it flows, step by step

Click a step to jump to it. Click a component for details.

What it does

A personal experiment to watch a home camera from a desktop app. A Node/Express backend logs in to the camera vendor's cloud, obtains WebRTC tickets and relays the signaling WebSocket, while a browser page and a .NET MAUI Mac Catalyst app act as clients.

The problem

The camera vendor only ships mobile apps. The goal was a desktop viewer with device status and controls, which required understanding the undocumented login, verification and WebRTC ticket flow.

What I built

  • Reconstructed the vendor's login, OTP verification and WebRTC ticket flow from captured traffic and app analysis.
  • Express REST layer exposing session, login, device status, attributes, control, dormancy and AI settings endpoints.
  • Custom WebSocket proxy that hand-builds the upgrade handshake and frames to relay signaling to the vendor over TLS.
  • Browser client negotiates WebRTC via RTCPeerConnection; a separate MAUI app with typed config and HTTP models targets macOS.

Key decisions and why

01

Local proxy instead of calling the vendor from the browser

A server-side layer can set the headers and request shapes the vendor API expects and handle the WebSocket upgrade that browsers cannot customize.

02

Endpoints configurable in appsettings

The MAUI client keeps API paths and probe toggles in typed options so protocol experiments can change without recompiling code.

03

Two clients over one backend contract

A zero-build web viewer allowed fast iteration on WebRTC, while the MAUI app explores a native desktop experience.

Tech stack

Languages
JavaScript (Node.js)C# / .NET 10
Frontend
.NET MAUI (Mac Catalyst)WebRTC
Backend
Express 5
Messaging
ws (WebSocket)
Other
mitmproxy traffic analysis