Privacy Policy

2.4. Private Mode

Seth offers a Private Mode for conversations that require extra privacy. When Private Mode is enabled:

• 🚫Messages are NOT saved to any database — they exist only in your browser's memory.
• 🔌The AI backend (ElizaOS) is completely bypassed — your message goes directly to the AI model via OpenRouter ZDR (Zero Data Retention) endpoint.
• 🧠Seth can still read his own reflections (read-only) to maintain personality, but nothing from your private conversation is written back.
• 🗑️When you close the tab, switch to normal mode, or refresh the page — the conversation is gone forever. There is no recovery.
• 📊No analytics, no logs, no conversation history is created for private conversations.

In short: Private Mode = zero persistence. Your words exist only in the moment.

2.5. Voice Input (Speech-to-Text)

Seth offers optional voice input for typing messages by speaking. When you use voice input:

• 🎤Audio is processed by your browser's built-in speech recognition service (Google Speech Services on Chrome/Edge, Apple Siri on Safari).
• 🚫Seth does NOT record, store, or transmit any audio data. We only receive the transcribed text that you choose to send.
• 🔒Audio processing happens between your device and your browser provider — Seth never has access to the audio stream.
• 📋The transcribed text appears in the message input field. You can review, edit, or delete it before sending.

In short: Voice input is a browser feature. Seth only sees the final text you send — never your voice.

5.1. Error Monitoring (Sentry)

We use Sentry (Functional Software, Inc.) for error monitoring and application stability. When an error occurs in the application, Sentry may automatically collect:

• 🖥️Technical information — browser type, operating system, device type, screen size.
• 🌐IP address — anonymized after 30 days by Sentry. We do not use it for tracking.
• 🐛Error details — stack traces, page URL where the error occurred, error messages.
• 🎬Session replay data — anonymized recordings of user interactions (all text and inputs are masked by default) to help reproduce and fix bugs.

What Sentry does NOT collect:

• ✕Conversation content or messages
• ✕Personal data (email, name) — we configure Sentry with sendDefaultPii: false
• ✕Payment information
• ✕Journal entries

This data is used solely for improving application stability and user experience. Sentry is GDPR-compliant (SOC2, ISO 27001) and acts as a data processor under our instructions. Error events are retained according to Sentry's default plan retention (typically 90 days), after which they are automatically deleted; IP addresses are anonymized after 30 days as noted above.

For more information, see Sentry's Privacy Policy

5.2. Operational Runtime Logs

For debugging, performance monitoring, and incident response, our backend (Railway) and frontend (Vercel) infrastructure write operational logs. These logs are designed to be PII-minimized by default:

• 🔢User identifiers (UUIDs) are truncated to an 8-character prefix (e.g. "75ace6c5…") — enough to correlate events within a single session burst, but not enough to reverse-link an account without database access.
• 🔐Conversation content, fact text, journal entries, learning insights, and message snippets are NEVER logged verbatim. When a log line would otherwise embed user content, we replace it with a length tag and SHA-256 hash prefix (e.g. "[len=78 hash=a3f8b2c1]") — collision-resistant for cross-line debugging, but cryptographically opaque to a log reader.
• ⏱️Railway backend logs are retained for 30 days and then automatically purged.
• 🛡️Database access (where the original content lives) is gated by Row Level Security policies — even with admin database credentials, queries are constrained to authorized rows.

What runtime logs do NOT contain:

• ✕Verbatim conversation messages, in any direction
• ✕Verbatim journal entries or fact claims
• ✕Email addresses, full names, or other directly identifying personal data
• ✕Payment information (handled exclusively by Stripe)

In short: runtime logs preserve enough technical signal to debug a bug ("which user, in which conversation, hit which code path"), without preserving enough content signal to reconstruct what was said. This is our implementation of GDPR Article 32 ("pseudonymization appropriate to the risk").