Show HN: Inbox Zero – open-source email assistant

Product scope & naming

• Several commenters note the name conflicts with the well-known “Inbox Zero” method and may confuse people or dilute the concept.
• Others see it as semantic drift: the tool’s goal is broadly to reduce email noise and help people get closer to an empty inbox, potentially evolving into a full email client.
• There is disagreement about any legal/trademark link to the original concept; the thread states the original creator is not involved and does not hold the trademark.

Platform support (Gmail vs “email”)

• The app currently supports only Gmail/Google Workspace via Google’s API.
• Some see this as pragmatic: Gmail has a large user base and a strong API, useful for early product–market fit.
• Others are frustrated that “email assistant” marketing masks a Gmail-only product, and argue that real innovation would target open protocols (IMAP/JMAP, Fastmail, Outlook, generic providers).
• A subset insists Gmail is just one email service and should not be treated as synonymous with “email.”

Privacy, trust & hosting

• A major concern is sending all email content to OpenAI and other third parties; several commenters consider this a non-starter.
• Multiple people want a fully local LLM and storage stack (IMAP/maildir, no external services).
• The project is open source and can be self-hosted; suggestions include using OpenAI-compatible local endpoints (e.g., LiteLLM + open models).
• Today it depends on Tinybird for data; data can be encrypted, and a future IndexedDB-only, no-backend version is mentioned.
• Some argue open source + Google security review improves trust; others say the stack is too complex to self-host conveniently and still demands significant trust.
• There is also a meta-discussion on how users can know the hosted code matches GitHub (answer: they essentially cannot; trust is required).

AI features & behavior

• Beyond newsletter cleanup, the app offers AI-driven automation and rule suggestions.
• Commenters like the idea of “planning mode,” where AI proposes actions (rules, replies) that users approve, rather than executing automatically.
• Comparisons are drawn to financial apps that auto-categorize transactions and learn via rules.
• Some propose running models in-browser (WebLLM) or swapping out GPT for models like Mistral; prompt tuning differences are noted but often minimal in practice.

Email workflows & philosophies

• Several users discuss using the inbox as a de facto todo list, especially in coordination-heavy roles, and struggle to truly reach zero.
• Various coping strategies appear: Gmail stars + snooze, separate folders/labels for “Follow up” and “Hold,” integration with dedicated todo apps (e.g., linking tasks to specific emails).
• Others advocate classic Inbox Zero/GTD-style processing: inbox as an intake bucket, with emails quickly triaged into action, waiting, or archive.
• Alternative philosophies include “inbox 10,000/20,000” where search and light archiving are considered sufficient, with occasional cleanups and unsubscribes.
• One long subthread presents a more abstract entity/graph model (tasks, messages, contacts, locations, etc.) and a personal system that links everything in a relational/graph structure, proposed as more general than conventional email/ticketing tools.
• Several people describe or link to their own local tools (Rust-based Gmail sorter with vim-like keybindings, SQLite-based bulk archiver, CLI/terminal clients like neomutt) that support rapid bulk classification without third-party services.

Unsubscribe & automation limits

• The app’s “one-click unsubscribe” is questioned: many newsletters require login or complex preference pages.
• Others note regulations typically require unsubscribe mechanisms in email bodies/headers; in practice, tools can sometimes use those directly, and otherwise fall back to auto-archiving per sender.
• Captchas and login walls on unsubscribe pages remain a practical obstacle beyond what any client can fully automate.

Pricing & positioning

• The project offers both SaaS and one-time license options, raising questions about pricing thresholds that would justify lifetime vs subscription.
• Current pricing is per account; the developer mentions interest in easing multi-account use later.
• Some commenters see the product as “just a feature” (bulk classification, smart rules) that large platforms might eventually subsume; others appreciate having a focused, user-facing tool even if it overlaps with built-in capabilities.