Settings
Account, connections, and the honest capability report for this deployment. Technical details live here, not on your home screen.
Account
The existing Supabase account and secure cookie session.
Server-verified OIDC. BDM never links Google to a password account just because the email matches.
- ID token signature, issuer, audience, expiry, and nonce are verified server-side.
- Only a verified Google email can create or link an account.
- Existing password accounts must sign in first before linking.
Add GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET to the server environment, then restart the service.
Add SUPABASE_SERVICE_ROLE_KEY and apply supabase/migrations/0004_google_identities.sql. Google sign-in stays disabled until the no-silent-linking guard is available.
In Google Cloud Console, create a Web application OAuth client and add the redirect URI above. Then enable the Google provider in Supabase Auth with the same client ID and secret: the session is still issued by Supabase, so BDM does not run a second auth system.
Capabilities
Provider readiness reported by the server. No secrets are shown.
Environment
Variable names and whether a value is present. Values are never read into this page, never shown, and never logged.
Privacy & retention
What leaves the app, and what stays.
Sent only for transcription, then discarded. BDM does not save the recording.
Only your question is sent to the search provider, never your chat history or memories.
Your Google ID token is verified server-side. The app stores a link between Google’s subject ID and your existing Supabase user.
Supabase auth cookies stay httpOnly and are refreshed by the server proxy.
Data & backup
Export your conversations and memories, or restore from a backup.