Open Brain: Mobile Capture with a Telegram Bot
Before you start: Part 2’s save and search tests should pass. This interface is optional. You can keep saving notes through Part 2’s tool and add browser access separately.
Done when: one Telegram message becomes one retrievable note, and a failed or interrupted save remains visible and recoverable.
A thought does not always arrive while the project workspace is open. A bot gives you a short route from a phone message to the same collection you already search. It is worth adding if opening a chat makes you more likely to save the note; otherwise, keep using the working capture method from Part 2.
I chose Telegram for practical reasons: setting up a bot looked straightforward, and I thought of it as a secure messaging app.
A bot message passes through Telegram and may reach an embedding provider. Ordinary bot chats are not end-to-end encrypted Secret Chats; restricting the bot to your account does not change that. Telegram explains chat encryption and what bots can see. Check employer, client, and research-data permissions as well as your own privacy preferences before sending real material.
Start with text
Use a dedicated bot and restrict it to your approved Telegram account. A hard-to-guess bot name is not an access-control mechanism.
Create it through Telegram’s official BotFather instructions, using /newbot. Enter the returned token directly into your protected configuration or credential store. Anyone with the token can control the bot, so do not paste it into the agent conversation or commit it to Git.
Next, have your agent show how to identify and configure the approved sender and chat using a synthetic test message. Check that messages from other identities are rejected before they enter the save pipeline. Creating the bot in Telegram does not start your application code.
Use a folder such as telegram inside the project workspace for bot code and its non-secret setup instructions, if that fits your project layout. Keep the bot token in a secure credential store or protected, untracked configuration, not in the code or a GitHub repository. See computer setup in Part 1 and GitHub privacy in Part 6.
The bot needs a process that keeps running. Your agent should select an approach suited to your computer or server rather than assume that a Mac-specific setup applies everywhere. Telegram documents its delivery options in the Bots FAQ.
If the bot runs on your computer, it stops when that process or the computer stops. Ask your agent where pending events are stored and how they can be recovered after a restart. That location depends on your design; a folder for bot code is not, by itself, a durable message queue.
In my implementation
The Telegram implementation reviewed for this series in October 2026 captures text through the Node save pipeline. In Part 1’s reading example, Spokenly turns my dictation into text before I send it through Telegram. That is different from sending an audio message for the bot to transcribe. Bot-side voice support would be an extension; the web app transcribes audio separately. The reliability requirements below are targets for a new build, not a claim that every failure case has already been solved in my current bot.
Prompt: add a narrow capture interface
Add Telegram text capture to the existing Open Brain save pipeline.
Inspect the project and current Telegram Bot API documentation. Explain
bot setup and where I should enter its token securely; never print it.
Allow only my explicitly approved Telegram user/chat identities. Reuse
the existing storage and metadata pipeline. Do not create a second,
incompatible database schema.
Give each incoming event a stable identity so retries cannot duplicate
notes. Preserve accepted input durably before acknowledging it, and
make failed processing visible and retryable. Distinguish "received"
from "saved and searchable."
Test unauthorized senders, duplicate delivery, a provider failure,
and a process restart using synthetic input. Document how to start,
stop, and inspect the bot. Ask before deployment or paid API tests.Check the result
Send “Test note: The code review is on Tuesday.” This synthetic exchange illustrates useful status messages, not the exact replies or verified behavior of my bot:
You: Test note: The code review is on Tuesday.
Bot, after durable acceptance: Received event <event-id>; processing.
Bot, after successful processing: Saved as <note-id>.
Alternative outcome during a simulated provider failure:
Bot: Event <event-id> is pending and recoverable; not yet searchable.The receipt should follow durable acceptance, so the bot can recover the event after a restart. Confirm the saved text and ID using Part 2’s get/search calls; this step does not require search inside Telegram.
Then have the agent simulate receiving that same event twice. There should be one saved note. During a simulated provider failure, the message should remain recoverable and should not be described as searchable.
Finally, stop and restart the process. Verify what happened to any pending message. A cheerful bot reply is not enough evidence that capture survived a failure.
Add voice only after text works
Voice capture adds a transcription step and may send audio to another provider. Transcripts can be wrong, so keep them reviewable. Approve the provider, retention choices, and costs separately from text capture.
Extend this tested bot to accept voice notes. Explain which provider
receives audio, retention choices, and expected costs before enabling it.
Obtain my approval before transmitting audio or running paid tests.
Keep the transcript available for review, handle unsupported or oversized
audio clearly, and reuse the same retry-safe save pipeline. Test one
synthetic recording in each language I use. Report transcription errors
without silently treating the transcript as an exact quotation.If a check fails
If the bot replies but search finds nothing, inspect the saved record and processing status before sending the note again. If duplicates appear, check the incoming event ID and how it is stored. If messages disappear after a restart, fix durable storage before relying on this capture route.
Next: improve retrieval without making the system unnecessarily complex.
Previous: the database and first search. For another way to access notes, see the browser interface.