Guardian
Guardian is the phone-facing memory client that grew out of 1Context’s earlier desktop, cloud, and VM experiments. It exists so a user can ask a personal assistant about accumulated project memory from a real phone, with the answer grounded in server-side relay state rather than a fragile local chat illusion. As of April 24, 2026, the visible app has been renamed Haptica, runs on Android and iOS Release builds, and remains tied to lab infrastructure while its relay, chat UX, and credential model are still being hardened.
Origin
Guardian first became concrete on March 25, 2026, when it stopped being only a design sketch and became a stack of working machines. That day produced a private guardianbackend repo, a Cloud Run service, Firestore state, GCS uploads, a Mac app with real Inventory data, a VM with per-user Linux accounts, and a Journal terminal path that did not require testers to install gcloud.
The earliest pressure was custody: source files, terminal sessions, Screenpipe-style capture data, VM accounts, and cloud import state all needed to belong somewhere. GuardianDesktop and guardianbackend formed that first answer. The system could ingest sources, display coverage, assign VM access, and record sessions, but it was still mostly a desktop/cloud archive rather than the phone assistant Guardian later became.
Role in 1Context
Guardian is one of the systems that made 1Context necessary. Before 1Context had its own name, Guardian already needed protected memory, durable chat continuity, authenticated callers, and evidence that could survive app restarts and network failures. The later 1Context framing separated the larger memory primitive from its consumers: Guardian became the main phone client, while Guardian Lab Relay became the server-owned execution layer behind the chat.
Guardian consumes memory and relay services rather than defining the whole architecture. It depends on a backend or relay to hold canonical turn state, model execution, uploads, and conversation continuity. It also contributes pressure back into 1Context: phone chat needs scoped identity, attachment handling, local transcript mirrors, service-grade model credentials, and a UX that can expose memory without pretending every answer is just a local message row.
History
The March 25-30 Guardian line began with imports and custody. The backend moved through Firestore, GCS, per-file upload records, batched upload routes, shard transport, VM reconciliation, janitor cleanup, and finally a reset toward Postgres and Cloud SQL after large Screenpipe imports exposed the limits of the earlier model. guardian-vm-01 became more than a test box: it gained per-user accounts, sync roots, transcript upload, and a pull-based reconcile loop.
On April 7, Guardian changed class. The new guardian-app became an Expo/React Native phone app talking over Tailscale to a TypeScript relay on the B650. The relay ran from /home/haptica/GitHub/Guardian_testing, reached Guardian memory through MCP, and returned real answers to a standalone Android APK. Commit e85f1ed474601bbd02cd200fa90af5b78d0799b3, Prove relay chat end-to-end on Android, marked the Android crossing with probe scripts and artifacts.
April 9 widened the device story. The relay became a user systemd service after a B650 power reset made the host disappear. The iOS lane also became real: the app built in Release, installed onto Paul’s iPhone, and later installed on Jacqueline’s phone, though developer trust blocked launch there under a personal development identity.
April 10 supplied the defining chat decision: execution is server-owned; streaming is observation. Guardian Lab Relay gained durable turns, replay, queued same-conversation sends, telemetry, lane scripts, and an experiment registry. The phone app bound pending assistant rows to accepted turnIds and learned to resume from canonical relay state after app switching. Commit d4e6c83, Preserve pending turns across iPhone app switching, captured the iOS side of that work.
On April 11, Guardian became Haptica in the visible app. Labels, placeholders, icon, splash, fonts, colors, dashboard copy, and iOS build metadata changed. The app also began migrating away from custom drawer behavior toward Expo Router drawer groups, centralized design tokens, primitives, haptics, and motion tokens.
By April 20-21, Haptica was being polished as a practical chat client. Work added retry, code copy, timestamps, rename and delete actions, share/export, attachments, queued composer behavior, photo permissions, server-backed starring, upload v2 routes, thumbnails, ffmpeg keyframe extraction, and attachment ordering diagnostics. One important bug showed the message could be sent before upload finalization, leaving the turn without attachment metadata.
Current State
As of April 24, Guardian remains the main phone-facing client for 1Context memory. It has Android and iOS lanes, local SQLite scaffolding, relay-backed chat, Release iOS builds that launch without Metro, and practical chat affordances including retry, stop, share, code copy, timestamps, rename/delete, queued composer behavior, attachments, and photo permissions. The app is no longer only a dev-server demonstration, but it still depends on lab relay infrastructure.
The largest unresolved issue is service auth for model execution. On April 18, the relay was found to be using Claude.ai OAuth credentials tied to a human subscription quota bucket rather than an Anthropic API key. The relay now reports upstream usage limits more honestly, but a phone-facing service still needs credentials, quotas, error taxonomy, and policy that are not bound to an individual account reset clock.
Related Subjects
Guardian is closely tied to Guardian Lab Relay, guardian-app, guardianbackend, GuardianDesktop, and Haptica. Its history also touches Puter, Fish, Littlebird, BookStack, and wiki-engine because each shaped the boundary between client behavior, memory custody, and the wider 1Context project.