Private product showcase / Pre-release candidate
Falcon
Every Google account. One calm cockpit.
One calm desktop for several Google accounts
Why this changes the game
Three reasons to care.
Every inbox, calendar, and contact in one calm cockpit.
Jump accounts without crossing identities or local checkpoints.
Turn an email into calendar action without tab pinball.
Proof today
The current machine, without mythology.
The scaffold includes unified inbox, Today, calendar, contacts, email-to-calendar flow, queued actions, offline cache/fallback, local SQLite, provider boundaries, and account-isolation tests. Live Google OAuth and real-account end-to-end proof remain the promotion gate.
Work and personal identities splinter across inboxes, tabs, calendars, and contact books; the mental switching becomes the real job.
A local-first native service normalizes mail, calendar, and contacts while keeping each identity, cache, provider checkpoint, and queued action separate.
The connected stack
Nothing powerful lives alone.
Public Academy
Learn Falcon from the inside.
Every public guide, field lesson, and architecture map for this system is gathered here. No membership is required to study these rooms.
Falcon: a local desktop for multiple Google accounts
Explore Falcon's multi-account mail, calendar, contacts, local cache, and account-isolation architecture. Learn which live Google checks a team should evaluate.
Open in the Academy ↗02 / Architecture mapFalcon interactive architecture
Select stations, trace routes, and see which layer owns each important Falcon decision.
Open in the Academy ↗Open the machinery
Follow the whole system.
See the route first. Then open the architecture or complete manual when you want every chamber, boundary, and proof.
InteractiveSee inside the systemOpen the architecture map ↗A glimpse inside
Six doors into the machine.
A local normalized layer between Google and the desktop
Falcon separates the WebView2 presentation shell, loopback service, provider-specific Google transport, normalized core models, account-scoped SQLite state, background scheduling, and verification executables.
A Windows host wraps a local focused client
Falcon.App embeds local HTML, CSS, and JavaScript in WebView2, launches or checks the loopback service, and presents one restrained shell for Mail, Calendar, Mail plus Today, Contacts, and Settings.
A loopback service owns state and provider actions
Falcon.Service binds a small HTTP server to 127.0.0.1, exposes bootstrap, capability, OAuth, sync, message, account, and mail-action routes, and coordinates database and scheduler lifetime.
Static configuration selects live or sample behavior
appsettings.json and an optional ignored resources/google-oauth.json control port, database, frontend path, telemetry, mock data, live Google mode, OAuth client metadata, and redirect port.
Browser consent returns through a validated local callback
The provider layer constructs a least-scope Google authorization request, validates callback state, exchanges codes and refresh tokens over HTTPS, and associates the resulting identity with one local account.
User tokens stay outside SQLite
Access and refresh token payloads are written to Windows Credential Manager under account-scoped targets; the database stores credential target metadata, granted scopes, and sync state rather than bearer material.
The door is open