title: Gday Meetings date: 2026-09-26 status: active scope: repository-overview

Gday Meetings

Gday Meetings has three independently runnable components: a native client, a server for users and meeting storage, and an audio-processing worker. They share this repository so their HTTP contracts and deployment instructions stay together. Each has its own dependencies and release lifecycle.

flowchart LR
    C[Native client on your Mac] -->|User OAuth: upload and retrieve| S[Server: CMS and durable storage]
    S -->|Authenticated job submission| W[Audio extraction worker: CPU or GPU]
    W -->|Download task inputs| S
    W -->|Persist typed results| S
    M[MCP client] -->|User OAuth: meeting search| S

The client must run in the host OS to receive microphone and system-audio permissions. The server needs ordinary CPU resources and persistent storage. The worker has a separate Python/ML runtime and can use CPU or GPU hardware. Keeping these as separate packages means installing the client does not install the CMS or model stack, and replacing a worker does not move the meeting database.

Related MCP server: MCP Zoom Recordings

Start the native client

SwiftUI client — Apple tools only

On macOS 26 or later, install Apple's Command Line Tools, wait for installation to finish, then build from the repository root:

xcode-select --install
make install-macos

This builds and locally signs Gday Meetings.app, then opens a Finder folder with an Applications shortcut. Drag the app onto Applications and open it. No full Xcode, Rust, CMake, Homebrew, Node, or Docker is required to build this client. Transcription uses a separately configured Gday Meetings server or compatible provider; AI features use your configured provider.

make start-macos builds and launches it; make build-macos only builds; make doctor-macos checks the selected Apple toolchain; make test-macos runs its tests. Xcode users can open apps/client-macos-swift/Package.swift. See the Swift client guide for permissions, features, and development.

The Swift and Rust apps have separate identities and local libraries and can be installed side by side.

Rust client

Building from source requires macOS 14.2+, Xcode Command Line Tools (Git/Make/Clang/SDK), stable Rust/Cargo, and CMake. Signing is automatic and needs no Apple Developer account. See macOS setup and troubleshooting for installation commands and runtime permissions.

From the repository root on macOS:

make doctor      # Check prerequisites before building
make start       # Build and launch the .app from the client build directory
make install     # Build and open Finder for drag-to-Applications installation
make help        # List client, server and worker commands

make start lets macOS choose an available port, opens the browser UI at that address, and streams logs until Ctrl+C. It neither installs to Applications nor starts Docker. make install opens a folder containing the app and an Applications shortcut; drag the app onto the shortcut, then open it from Applications. The installed app starts the client and opens its UI without needing the repository. This is a local ad-hoc signed build, not a notarized public binary release.

All client launches save daily logs under ~/Library/Logs/Gday Meetings/, retaining up to 14 files. This includes double-clicking the installed app in Finder.

The macOS app's waveform menu bar icon lets you reopen the browser UI, see recording status, show logs, and quit gracefully. Closing the browser leaves the client running.

The server and worker are deployed independently and can live on different hosts. Each owns its Dockerfiles, Compose files and .env.example. Follow deployment, then use Settings → Services → Login to Gday Meetings Server in the client to connect to your server URL. Complete first-user setup at the server's /admin page first. The native client currently supports macOS; Make reports unsupported client platforms explicitly.

CPU execution takes longer than GPU execution. Model downloads require network access initially; speaker diarization additionally requires access to gated Hugging Face models. Once the required models are cached, processing can remain local. Local deployment does not require RunPod.

Repository layout

apps/
  client-macos-swift/      Native SwiftUI client, Swift package, macOS packaging
  client-macos-rust/       Rust client, UI, Cargo files, scripts and macOS packaging
  file-drop/              Optional helper for the direct RunPod workflow
  server/                 Payload/Next.js CMS, auth, APIs and server tests
  worker-audio-extraction/ Python ML worker, local HTTP and RunPod adapters
integrations/             Reserved Logseq and Obsidian integrations
docs/                     Architecture, deployment, and worklogs
Makefile                  Common commands delegating to independent components

The Rust client binary is gday-meetings-client and its macOS bundle is Gday Meetings Rust.app. Its existing local data paths and macOS app identity are preserved. The SwiftUI client is packaged as Gday Meetings.app, with a separate bundle identity and library. The source folder remains apps/client-macos-swift. The server source was brought back from the Gday Meetings repository; existing database names and previously published images retain their identities.

The GitHub repository URL still uses meeting-notes. Our domain is gdaymeetings.com. The native SwiftUI app uses com.gdaymeetings.macos and stores meetings in ~/.local/share/com.gdaymeetings.macos/. The Rust client uses com.gdaymeetings.macos.rust with a separate library because the formats differ. Both clients preserve their old libraries during migration; recording permissions may need to be granted again after the identity change. Historical worklogs and release notes retain their original names.

Deployment and development

• Architecture and integration contracts

• Service provider capability protocols

• Local CPU, local GPU and cloud deployment

• Client usage and macOS permissions

• Server setup and API documentation

• Worker runtime and model setup

• Client/server login and existing-meeting migration

• Deferred Payload collection redesign

Each component's README describes its own install and test commands. make test-client, make test-server and make test-worker run the respective suites. There is no root Cargo workspace, package manifest or Docker stack. Server container releases use server-vX.Y.Z tags and the independent package version in apps/server/package.json.