We looked into the specific issue you mentioned. Collapsing replies does exist in the product, but we found it doesn't work for emails sent from Outlook (our guess on why you might have faced this). We are fixing this in the next release, shipping this week. Hope you give it a try.
Thank you! And would love to share notes. The tiny-models-only discipline is interesting; we do special handling just to keep local models from being overwhelmed, so I'd like to hear how far you've pushed it. You can find me on Discord, if you want to chat on anything.
Yes! You can use local models through Ollama and LM Studio. We do some special handling when you use local models, such as suppressing background agents when you chat, so the model is not overwhelmed.
Local-first for us means: your data such as emails, notes, meetings, the knowledge graph - lives on your machine as plain Markdown, readable and deletable, and the app doesn't require our servers to run. You can also go fully local for the LLM with Ollama or LM Studio. We do special handling there, like suppressing background agents during chat, so local models aren't overwhelmed. That's the core of the product.
Some third-party APIs we couldn't avoid (search has to be an API call). For TTS/STT we deliberately chose cloud quality over local support for now - if there's demand, we'll support local.
On PostHog: usage metadata only, never content. Anonymous install ID unless you sign in to Rowboat; email and plan attached after. Everything sent is cataloged in apps/x/ANALYTICS.md. We shipped v1 with no analytics and were flying little blind on whether anyone used it. If you build without the PostHog env vars, it no-ops entirely.
Instead of having to define what “local-first” means to you personally you should emphasize that the data lives on your local machine. For some example messaging take a look at how Apple is marketing their new Siri AI.
That's fair - "your data lives on your machine as plain files" is the concrete claim, and something we should lead with. Will take a look at how Apple frames it, thanks.
You have completely misused and re-purposed this term. The common interpretation is that the software will continue to function without an internet connection which is not the case for your product.
Yes! Under settings you can connect your WhatsApp or Telegram and chat with the assistant. It can query your knowledge and trigger coding tasks.
In addition, we have a caffeinate mode (in new release) that keeps your machine awake so the connection doesn't drop. We are also working on a mobile app.
1. True - no OS-level container today. The constraint is approval gating: consequential actions surface as a permission ask before they run (a separate supervisor LLM flags anything outside your intent).
2. True today. We'd deprioritized generic IMAP (drafts-on-thread is unreliable cross-provider), but you're the third person in this thread to raise it, so we'll scope it properly.
3/4/5. Today: Deepgram for STT, ElevenLabs for TTS, Exa for search.
At least for search we supported more providers earlier (e.g. Brave) and found the assistant's skills degrade when they can't lean on provider-specific capabilities, like Exa's granular search. So we trimmed and went deep on a few.
Feel free to raise a GitHub issue with what you want us to support and we'll do our best.
Thank you for addressing my list. I'd like to use it, but requirements on non-local services is a deal breaker for me.
Right now, with my Nanoclaw, I'm running it in a container on a VM on proxmox. If things get bad, I lose a backed up machine and any services it has credentials to.
I can understand why IMAP is a pain. There's plenty of functions that can trash mailboxes. I don't envy you all in this task.
And OpenWhispr is local Whisper model that I also run locally. And still, no data leaks. And since its local, its also FAST. I also use it via HomeAssiatant.
For search, I use SearXNG. Ive even changed my daily driver to it at home, since it gets great results and none of the public cloud forced crap (llm searches when I don't want it).
Thanks for the concrete list! I understand where you are coming from.
Will go through these and see what we could support. If you drop your stack into a GitHub issue, that's the best place for us to work through it (and for others to +1).
We looked into the specific issue you mentioned. Collapsing replies does exist in the product, but we found it doesn't work for emails sent from Outlook (our guess on why you might have faced this). We are fixing this in the next release, shipping this week. Hope you give it a try.