Telegram bot as mobile memory capture and retrieval channel

Research Question

Can a Telegram bot serve as a low-friction mobile capture and retrieval surface for the Memory-System? Specifically: (a) message received → file written to GitHub repo via API, (b) messages starting with ? trigger semantic search via search_brain and reply with results, (c) what is the minimum hosting requirement (Raspberry Pi, VPS, free tier Platform as a Service (PaaS))?

Findings

(Populated from §6 Synthesis above.)

Executive Summary

A Telegram bot can serve as a viable mobile memory capture and retrieval surface for the Memory-System. The capture path — message received → inbox/YYYY-MM-DD-HHmmss.md committed to the GitHub repository via the Contents API — is fully implementable using long-polling with python-telegram-bot and a fine-grained PAT. Long-polling requires no public URL or inbound network access. Render free tier is incompatible with long-polling; Raspberry Pi (existing hardware) and Oracle Cloud Always Free ARM VM are the strongest zero-cost hosting options. The Telegram path complements iOS Shortcuts by extending capture to non-iOS devices and always-available chat sessions, at the cost of requiring a continuously running hosted process.

Key Findings

1. Telegram long-polling via getUpdates with timeout=30 delivers messages within approximately one second, requires no public URL, no inbound firewall rules, and no OAuth flow — only a single bot token obtained from BotFather in a single chat conversation.
2. The capture path is a direct reuse of the GitHub Contents API PUT pattern from the iOS Shortcuts research: base64-encode the message body, construct a second-precision filename (inbox/YYYY-MM-DD-HHmmss.md), and call PUT /repos/{owner}/{repo}/contents/{path} with a fine-grained PAT scoped to Contents: write on the Memory-System repository.
3. Owner-only bot security is enforced by checking update.message.from_user.id against a hardcoded OWNER_CHAT_ID environment variable; this is the correct pattern [inference] because Telegram chat IDs are static and stable for a given user account.
4. Render's free web service tier spins down after 15 minutes without inbound HTTP traffic, which is never generated by a long-polling bot; Render free tier is therefore incompatible with long-polling and only viable in webhook mode, which introduces approximately one-minute cold-start delays.
5. Railway's free plan provides $1/month of resource credit, which is marginally insufficient for a 24/7 always-on Python process at estimated costs of $1.15–1.75/month; the Railway Hobby plan at $5/month (with $5 included usage) covers the bot at zero marginal cost within the plan allowance.
6. Fly.io has no genuine free tier for Fly Machines as of March 2026; the cheapest always-on Fly Machine (shared-cpu-1x, 256MB RAM) costs approximately $2.02/month continuously running, which is viable but not free.
7. A Raspberry Pi running the bot as a systemd service represents the lowest-cost always-on hosting option at near-zero incremental electricity cost (~$1–3/year), with Tailscale's free Personal plan providing optional remote SSH access; this is the recommended hosting path for users with existing home hardware.
8. Oracle Cloud's Always Free tier provides ARM VM compute (up to 4 OCPUs and 24GB RAM total across Always Free instances) with no expiry, making it the best zero-cost cloud option [inference] for users without home hardware, though Oracle's terms could change.
9. The Telegram bot path and iOS Shortcuts path are complementary. iOS Shortcuts has a clear advantage for Siri hands-free voice capture and zero-maintenance operation [inference]; the Telegram bot's value lies in cross-platform availability, always-on reliability independent of the iOS device, and retrieval via chat interface [inference].
10. End-to-end capture latency is estimated at 500ms–1.2s (Telegram polling delivery plus GitHub Contents API write); retrieval latency is dominated by the search_brain execution time, which is out of scope for this item but is the primary variable in the user experience.

Assumptions

• Assumption: search_brain is callable as a Python function or subprocess from the bot process. Justification: Memory-System W-0011 defines search_brain as callable; implementation is out of scope for this item.
• Assumption: Oracle Cloud Always Free ARM VM remains available in its current form. Justification: The program launched in 2021 and has operated continuously; widely used. Risk: Oracle could change terms without notice.
• Assumption: The user already has a Telegram account. Justification: Telegram has 900M+ monthly active users; reasonable baseline for the target personal-use scenario.

Analysis

Telegram's long-polling architecture is well-matched to a personal memory bot. The single-token credential model, no-public-URL requirement, and simple message event handling make it significantly simpler to deploy than a Slack bot (which requires two tokens, a workspace, and Socket Mode configuration). The capture path is an exact structural parallel to the iOS Shortcuts path — both call PUT /repos/.../contents/inbox/{filename}.md — which means the GitHub API layer is already validated by prior research.

Hosting dominates the implementation decision. The evaluation reveals a clear hierarchy: Render free is non-viable (wrong spin-down model); Railway free is borderline-insufficient; Fly.io requires payment; Raspberry Pi and Oracle Cloud Always Free are genuinely zero-cost. For users with existing home hardware, Raspberry Pi is the obvious choice [inference]. For cloud-only deployments, Oracle Cloud Always Free is recommended over Fly.io or Railway free.

Both paths are complementary: iOS Shortcuts retains a UX advantage for voice capture [inference]; running them simultaneously gives the broadest capture coverage.

Risks, Gaps, and Uncertainties

• Oracle Cloud risk: Always Free terms could change; migrations to paid tiers would be required if the program ends.
• Railway cost estimate: The $1.15–1.75/month estimate is based on assumed idle resource consumption; a bot handling more messages would consume more CPU, potentially increasing costs.
• search_brain integration gap: Retrieval latency and result quality are entirely dependent on the search_brain implementation, which is out of scope. A slow or unavailable search_brain makes the retrieval feature non-functional.
• Chat ID security limitation: from_user.id is not secret — it is visible to any bot or service the owner interacts with on Telegram. The security model relies on the owner's chat ID not being guessed or leaked. This is acceptable for a personal bot with no sensitive data consequences.
• Telegram data privacy: Message content passes through Telegram's servers. For notes containing sensitive personal information about third parties, this creates potential GDPR considerations in EU/UK jurisdictions.

Open Questions

1. Voice message transcription: Should the bot support Telegram Voice message objects (voice memos → transcription → stored as text)? This would add Siri-equivalent hands-free capture. May warrant a separate backlog item.
2. search_brain integration architecture: What is the correct integration point — subprocess CLI call, Python function import, or MCP tool invocation? This is the key unresolved technical question for the W-0011 implementation.
3. Direct file creation vs GitHub Issues: Should the Telegram bot write to inbox/ (Contents API, same as this research recommends) or create GitHub Issues (simpler API call, same as iOS Shortcuts path)? The inbox folder triage pattern (2026-03-08-inbox-folder-capture-triage-pattern.md) suggests direct file creation is preferable.
4. Bot health command: Is there value in a /status command reporting the bot's uptime, recent capture count, and last commit SHA?

sources

• [x] Research/completed/2026-03-02-agent-memory-management-context-injection.md — production memory system patterns; context on why unified capture + retrieval surfaces are valuable
• [x] Research/completed/2026-03-08-slack-bot-memory-capture-retrieval.md — Slack vs Telegram comparison, Socket Mode equivalence with long-polling, GitHub Contents API patterns
• [x] Research/completed/2026-03-02-ios-shortcuts-research.md — iOS Shortcuts comparison baseline; GitHub Contents API write pattern
• [x] Telegram Bot API docs
• [x] Telegram Bot API getting-updates
• [x] Telegram Bot tutorial
• [x] GitHub Contents API docs
• [x] Railway free tier docs
• [x] Fly.io pricing docs
• [x] Render free tier docs
• [x] Tailscale docs (for Raspberry Pi home server)