feat: integrate Recall SDK for meeting detection and recording

[lucasheriques]

Notetaker: Meeting Recording & Transcription

Automatic recording and transcription for Google Meet, Zoom, Teams, and Slack.

Architecture

Key decision: Zustand is the single source of truth. Main process only coordinates.

Why Zustand for state management:

• React focuses on UI - Components subscribe to Zustand and re-render automatically
• Fast client-side interactions - Real-time transcript updates, notes editing, all local-first
• Batch sync to backend - Upload every 10 segments/10s instead of per-segment (reduces API load)
• IndexedDB persistence - Crash recovery without losing active meeting data
• Simple architecture - Main process forwards events, doesn't manage meeting state

flowchart TB
    subgraph Main["Main Process (recallRecording.ts)"]
        Recall[Recall SDK]
        Flag[isRecording flag]
        Map[windowToRecordingMap]
    end

    subgraph Renderer["Renderer (recordingService.ts)"]
        Zustand[Zustand Store]
        Batch[Batch Upload<br/>10 segments or 10s]
    end

    Recall -->|meeting-detected| Flag
    Flag -->|if false| Recall
    Recall -->|IPC: events| Zustand
    Zustand -->|persist| IDB[(IndexedDB)]
    Zustand -->|subscribe| UI[React UI]
    Batch -->|segments| API[PostHog API]
    Zustand -.->|triggers| Batch

    style Zustand fill:#4CAF50
    style Flag fill:#FFC107

Loading

Data flows:

1. Meeting starts → Recall detects → Main checks isRecording → Creates recording in API → Sends IPC → Zustand stores → UI updates
2. Transcript arrives → Recall forwards → IPC → Zustand stores → UI updates live → Batch upload every 10 segments/10s
3. Meeting ends → Recall notifies → Upload remaining segments → Video uploads → Status "ready" → Zustand clears → UI shows in past meetings

State:

• Main: isRecording (deduplication), windowToRecordingMap (Recall SDK only provides windowId, we need to map it to our recordingId)
• Zustand: segments, status, notes (persisted to IndexedDB)

Current Limitations

• One meeting at a time - isRecording flag prevents concurrent recordings (by design for v1)
• No retry UI - Segment upload failures are logged but not exposed to user (crash recovery handles most cases)
• No metrics yet to track success/failure on meeting recordings - will work on those after I finish a v0

What to Review

Core files:

• src/main/services/recallRecording.ts - Recall SDK integration, event forwarding
• src/renderer/services/recordingService.ts - IPC handlers, batch uploads, crash recovery
• src/renderer/stores/activeRecordingStore.ts - Recording state management

Watch for:

• Main process forwards events, doesn't manage state
• Types use Schemas.DesktopRecording from generated API (not custom interfaces)
• Deduplication is a simple isRecording boolean check (no IPC)

Special thanks to @rafaeelaudibert on his tip to keep all Recall's state outside of React. ❤️

[lucasheriques]

• feat: integrate Recall SDK for meeting detection and recording #65 : 2 dependent PRs (#67 , #73 ) 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[jonathanlab]

Great stuff, I like the IDB usage 🚢

[lucasheriques]

Merge activity

• Oct 29, 12:55 PM UTC: A user started a stack merge that includes this pull request via Graphite.
• Oct 29, 12:55 PM UTC: @lucasheriques merged this pull request with Graphite.