---
title: "Guardian"
slug: guardian
section: reference
access: public
summary: "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…"
status: published
asset_base: /assets
home_href: /
toc_enabled: true
talk_enabled: false
agent_view_enabled: true
copy_buttons_enabled: true
footer_enabled: true
last_updated: 2026-04-29
categories: [Projects, Tools]
subject-type: project
project-status: active
aliases: [guardian-app, guardian-system]
last-reinforced: 2026-04-29
fading-since: null
archived: false
---

## 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](/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](/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](/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](/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](https://www.postgresql.org/) 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](/guardian) became an Expo/React Native phone app talking over [Tailscale](https://tailscale.com/) 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](/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 `turnId`s 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-lab-relay), [guardian-app](/guardian), guardianbackend, GuardianDesktop, and [Haptica](/haptica). Its history also touches [Puter](/puter), [Fish](/fish), [Littlebird](/littlebird), [BookStack](/bookstack), and [wiki-engine](/wiki-engine) because each shaped the boundary between client behavior, memory custody, and the wider [1Context](/1context) project.