Anghkooey

You shouldn't have to explain yourself twice.

A personal AI concierge that remembers how you like things.
Anghkooey brings relevant preferences, constraints, and past experiences back into your next conversation — starting with hotels, travel, and dining.

Explore the experience · How memory works · Run locally · Architecture · Documentation

---

Why Anghkooey?

Most assistants can answer a question. Fewer can carry forward the reason behind your preferences.

A quiet hotel room matters differently when you've said road noise kept you awake on your last trip. Anghkooey is designed to remember that context — when you consent to saving it — and use it when it becomes relevant again.

The idea is simple: remember the preference, preserve the reason, and let the person correct it when life changes.

The experience

Experience	What you can do
Web chat	Start a real DeepSeek conversation in the browser, without email signup or a wallet.
Memory, by choice	Opt in before Anghkooey saves lasting preferences to Walrus Mainnet. Chat remains usable with memory saving off.
Personalized recall	Receive answers informed by relevant, previously saved Walrus memories, with recall receipts when available.
Memory library	Browse confirmed memory metadata, filter by category/status, and search for matching stored facts.
Corrections	Replace an outdated preference with a new confirmed Walrus memory; the old record is retired from recall, not deleted from Mainnet.
Linked conversations	Connect a browser identity with Telegram or an iMessage chat using a single-use code and verified in-channel approval when accounts need consolidating.
Privacy controls	Change memory consent and end a browser session, with clear information about what each action does not erase.

Channel availability: web chat and the Telegram bot are the public entry points. iMessage is integrated through Photon but remains in testing; no public contact is advertised here.

TasteProof × Qloo: culturally grounded dining

Hackathon addition (October 2026): TasteProof connects Anghkooey's memory-aware concierge to Qloo's cultural-intelligence API. The rest of Anghkooey — DeepSeek chat, Walrus memories, Neon identity, Photon messaging — is the pre-existing product; Qloo is the new taste layer.

Problem: travel assistants forget why you liked a place, and generic "best restaurants" lists ignore your taste. Solution: Anghkooey resolves named cultural anchors you approve (e.g. Nobu Restaurant) through live Qloo Search, confirms each exact entity, then runs Qloo Insights for the destination city — grounding recommendations ONLY in the venues Qloo actually returns, with photos, tags, affinity, and explicit correction/Undo plus a live single-versus-multi comparison.

Multi-anchor proof (live, production): confirm Nobu Restaurant (FF6EE520) plus Ryuichi Sakamoto (B0DEDE63, provider-typed artist) in Lagos — one combined Insights request returns ILE EROS LAGOS, Izanagi Japanese Cuisine, and NOK by Alara with both anchors attributed on every venue, versus the single-anchor baseline (Izanagi, ILE EROS, Talindo). Text-panel evidence below is captured from the deployed app during release verification; venue photographs appear only in the previously approved card shots (credit: Qloo).

How the agentic flow works

1. You ask in web chat (/chat): “Find dining like Nobu in Lagos.”
2. The concierge proposes — it does not fire yet: it names the exact anchor and city and asks for a yes. No external Qloo lookup fires until you approve.
3. On approval it runs live Qloo Search first, then waits for entity confirmation (exact name, type, and ID shown; ambiguous names present choices; stale selections are rejected). Only a freshly confirmed entity ID drives Qloo Insights (server-side, strict per-user rate limit, only approved strings cross to Qloo).
4. DeepSeek answers grounded in the returned venues only, separating (a) Qloo's cultural signal, (b) your remembered preferences, and (c) what is NOT verified (availability, prices, bookings).
5. Missing details are asked, never invented: no city → it asks for one; no named anchor → it asks for one and won't guess.
6. Corrections re-propose: “make it Terra” starts a new proposal needing a fresh yes; denials and unrelated questions never trigger a lookup.

TasteProof visual discovery (/taste)

The same live Qloo evidence rendered as inspectable photographic cards: venue photo, Qloo description, cultural tags, address, and Qloo affinity — explicitly labeled as Qloo's ranking signal, never a match percentage.

Change the anchor and TasteProof reruns Qloo, showing a real before/after comparison (added/removed/reordered by actual Qloo IDs) with an Undo that restores the prior result without another lookup.

The layout is responsive — the same discovery on a phone:

Memory honesty

Your saved Walrus memories can suggest a taste anchor (the memory panel mines capitalized names from your own words), but raw memory content, reasons, and identifiers are never transmitted to Qloo: Qloo receives the approved anchor/city inputs, resolves the anchor to a Qloo entity, and that Qloo-returned entity ID drives the Insights lookup. Separately, relevant recalled memories may be included in DeepSeek prompts to shape the recommendation text — that stays between our server and the chat model, never Qloo. Dining turns are session-only and never written as durable memories. The demonstration below works with memory saving OFF: “Nobu” is typed by hand, not recalled from a saved memory.

Where Qloo sits in the architecture

flowchart LR
    U[User] --> CHAT[Web chat / /taste]
    CHAT --> APP{Explicit approval?}
    APP -- yes, anchor + city --> QLOO[Qloo Search + Insights\nserver-only, rate-limited]
    APP -- no / missing details --> ASK[Clarify or stand down]
    QLOO --> EV[Typed evidence:\nvenues, tags, affinity, photos]
    EV --> DS[DeepSeek Flash\ngrounded answer only]
    DS --> U
    MEM[(Walrus memories)] -. suggest only .-> APP

Try it (no credentials needed)

1. Open https://anghkooey.vercel.app/taste — anchor and city are pre-filled (Nobu Restaurant, Lagos).
2. Press Find dining candidates, confirm the FF6EE520 entity. Real Qloo venues appear with photos and evidence.
3. Change the anchor to Terra Kulture, press Approve revised Qloo lookup, and watch the before/after comparison. Press Undo to restore.
4. Multi-anchor: press Add another anchor, enter Ryuichi Sakamoto, Resolve anchors, confirm both entities, review the combined approval summary, press Approve combined discovery — expect the joint set with per-venue anchor attribution, then Compare with Nobu Restaurant alone and check What actually ran.
5. Or use /chat: “Find dining like Nobu in Lagos” → say “Yes” → confirm the exact entity → grounded recommendation. (Memory panel use is optional; memory saving stays OFF — demo anchors are typed, not recalled.)

What was added during the hackathon

Server-only Qloo adapter (Search + Insights with feature.explainability, trustworthy entity resolution, per-entity attribution, strict fail-closed rate limiting), /api/tasteproof (GET single-anchor + POST multi-anchor with fresh revalidation), the /taste page with photographic evidence cards + correction/Undo + multi-anchor combined discovery with single-versus-multi comparison, execution trace, and a recorded no-Qloo baseline, the chat approval gate with entity confirmation and full-message affirmative precision, Qloo-grounded DeepSeek prompting, and synthetic regression suites. Nothing else changed: no migrations, no new infrastructure, no Photon/Gmail/Walrus behavior changes.

Verification evidence and limitations

• Focused suites: 319 passed / 67 intentional skips DB-less (isolated-DB suites skip honestly), incl. adapter parsing, approval consent, correction comparison, multi-anchor contract, rate-limit fail-closed. Desktop/mobile Playwright: 28/28 intercepted journeys (multi-anchor resolve/confirm/discovery, comparison, stale-invalidation, trace) with zero console errors.
• npm audit --omit=dev: zero high/critical advisories (18 moderate Spectrum/OTel worker-telemetry advisories with no compatible fix).
• Live-verified on production: single Nobu → FF6EE520 + Izanagi / ILE EROS / Talindo; combined Nobu FF6EE520 + Sakamoto artist B0DEDE63 → ILE EROS / Izanagi / NOK by Alara with both anchors attributed per venue; all photos load with entity-matched URLs; empty/gibberish anchors return honest errors; stale selections rejected.
• Limitations: venue notes depend on Qloo coverage (thin venues show names + ranking only); Qloo affinity is a per-request ranking signal, not a match probability and not comparable across requests; availability, prices, and bookings are never verified; the live chat voice still awaits a recorded owner browser pass.

Product gallery

Visual placeholders: Add your actual screenshots to docs/media/ before publishing a demo-focused README. These slots are deliberately labelled rather than displaying invented product screenshots or broken image links.

Demo video: [Add your public demo link here after publication].
Mainnet evidence: [Add a sanitized proof/evidence link here when available; do not expose user content].

How memory works

1. Tell Anghkooey what matters. Share a hotel, travel, or dining preference and, ideally, why it matters.
2. Choose whether to remember it. Saving new long-term memories requires explicit consent.
3. Confirm the save. The server extracts meaningful facts and waits for an actual Walrus Mainnet write; a success label is shown only after confirmation.
4. Return and ask again. Anghkooey searches the correct user namespace for relevant memories and supplies that context to DeepSeek Flash.
5. Correct it later. Corrections append a new memory and mark the older record as superseded for future recall.

For example:

You: “I avoid rooms facing busy roads because traffic noise keeps me awake.”
Later: “What should I prioritize when choosing a hotel?”
Anghkooey: Can use the confirmed preference and its reason to advise prioritizing quieter rooms, without pretending to know live availability.

This exchange is illustrative; it is not a quoted or fabricated production chat transcript.

One person, three conversations

Web, Telegram, and iMessage use the same conversation engine. Linking is not automatic: a web session generates a one-time, 10-minute code, which the user sends to Anghkooey inside the target messaging channel. Photon verifies the actual sender. If that channel already has a separate memory account, the person explicitly approves consolidation with MERGE YES (or declines with MERGE NO). Existing memories remain in their original Walrus namespaces and are recalled through authorized identity aliases.

Important: an anonymous browser session is not a recoverable email login. Clearing cookies, ending the session, or switching devices can prevent access to that specific web identity. Wallet connection is not required and does not confer individual custody over memories in the current architecture.

Architecture

flowchart TB
    U[User] --> W[Web app / Next.js]
    U --> TG[Telegram]
    U --> IM[iMessage - in testing]
    TG --> P[Photon Spectrum Cloud]
    IM --> P
    P --> WK[Persistent Photon worker / AWS EC2]
    W --> API[Authenticated web API]
    API --> CORE[Shared conversation orchestrator]
    WK --> CORE
    CORE <--> DS[DeepSeek Flash]
    CORE <--> DB[(Neon PostgreSQL / sessions, links, metadata)]
    CORE <--> MW[MemWal SDK]
    MW <--> WAL[(Walrus Memory Mainnet)]

Where things live:

• Vercel: Next.js app, chat UI, memory/profile/settings pages, and server-side API routes.
• AWS EC2: exactly one supervised, continuously running Photon worker for messaging.
• Neon PostgreSQL: user/session identities, consent, channel links, idempotency, temporary conversation history, and Walrus blob metadata.
• Walrus Mainnet: durable memory facts stored through @mysten-incubation/memwal. Neon is not a replacement long-term preference store.
• DeepSeek Flash: the deployed conversation model, independent of any coding assistant used to build the project.

Technology

Layer	Technology
App	Next.js 16, React 19, TypeScript
Styling and motion	Tailwind CSS 4, GSAP / ScrollTrigger, Cormorant Garamond, Satoshi, Georama
AI	DeepSeek Flash
Durable memory	Walrus Mainnet via MemWal SDK
Database	Neon PostgreSQL
Messaging	Photon Spectrum (spectrum-ts) for Telegram and iMessage
Hosting	Vercel (web) and AWS EC2 + systemd (worker)

Run it locally

Prerequisites

• Node.js 24.x recommended (the production web deployment uses Node 24).
• npm, Git, a Neon Postgres database, DeepSeek API access, and Walrus Memory Mainnet credentials.
• Photon project credentials and a Telegram bot token only if running the messaging worker.

1. Clone and install

git clone https://github.com/Devendurance/anghkooey.git
cd anghkooey
npm ci

Clean npm ci with no extra flags is the expected state; peer ranges resolve without --legacy-peer-deps or --force. Don't run npm audit fix --force as a substitute.

2. Configure server secrets

# Copy the template only if .env does not already exist.
test -e .env || cp .env.example .env

Edit .env locally. Never commit it, paste credentials into issues, or expose keys through NEXT_PUBLIC_* variables.

Setting	Purpose
DEEPSEEK_API_KEY	DeepSeek API credential
DEEPSEEK_BASE_URL	DeepSeek API base URL (template includes a default)
DEEPSEEK_MODEL	deepseek-flash
DEEPSEEK_THINKING	Optional; defaults to disabled for normal chat and extraction
DATABASE_URL	Neon PostgreSQL connection string
APP_SESSION_SECRET	Secret used to protect opaque session tokens; use a strong random value
WEB_BASE_URL	Local URL in development; public HTTPS origin in production
MEMWAL_PRIVATE_KEY	Server-only MemWal private credential
MEMWAL_ACCOUNT_ID	Application-managed MemWal account identifier
MEMWAL_SERVER_URL	Mainnet relayer URL (template includes a default)
PHOTON_PROJECT_ID	Photon project identifier, for the worker
PHOTON_PROJECT_SECRET	Photon server credential, for the worker
TELEGRAM_BOT_TOKEN	Telegram bot credential, for the worker
QLOO_API_KEY	Qloo hackathon API credential (server-only; required for TasteProof)
QLOO_BASE_URL	Qloo API base URL (optional; defaults to the hackathon endpoint)

The repository's .env.example is the canonical variable-name reference.

3. Prepare the database and run the web app

# Apply the existing migrations to your intended database only.
npm run migrate

npm run dev

Open http://localhost:3000. The web chat is at /chat; the memory archive is at /memories.

Do not run migrations against a live database casually. The deployed project uses an existing migrated Neon database. Use a separate development database when experimenting.

4. Optional: run the messaging worker

npm run photon:readiness
npm run worker:start

Only one Photon worker instance should listen to a given project at a time. If the AWS production worker is running, do not start a second local worker with the same Photon credentials; competing workers can duplicate deliveries and replies. See the Photon deployment guide.

5. Checks

npm test
npm run typecheck
npm run lint
npm run build
npm run check:integrations

Some integration tests require database access. Real-Neon suites skip honestly when DATABASE_URL is empty (clean-checkout default); set an isolated QA branch URL explicitly to run them — never point them at production. photon:readiness is the dedicated Photon check; the generic integration checker may contain legacy Photon status wording. Scripts such as smoke:memory and test-channel-flow can perform real, chargeable Mainnet writes — run them deliberately, not as routine build checks.

# DB-less intercepted browser suite (no secrets, no prod writes).
# Builds, starts a local QA server on 127.0.0.1:3101, runs 14 Chromium
# checks (desktop + mobile, live-Qloo test excluded), then stops the server.
npm run test:e2e:intercepted

Project structure

src/app/                  Next.js pages and HTTP routes
src/components/           Landing, brand, and app experiences
src/server/               Sessions, identity, DeepSeek, Walrus, orchestration
src/lib/                  Shared site configuration and client helpers
workers/photon-worker.ts  Long-running Telegram/iMessage consumer
db/migrations/            PostgreSQL schema and migration history
scripts/                  Readiness, verification, and migration utilities
tests/                    Automated regression and integration tests
docs/                     PRD, TRD, architecture, deployment guides
public/brand/anghkooey/   Branding and production artwork

Trust, security, and current limits

• Opt-in durable memory. Memory writes are gated by consent; existing memories may still be recalled when new saving is disabled.
• Scoped retrieval. Sessions and verified channel identities determine which Walrus namespaces may be searched.
• Verified linking. One-time codes are hashed in the database; Telegram/iMessage identity comes from authenticated Photon events, not a user-entered display name.
• Transparent provenance. Chat can show a recalled memory receipt or a confirmed new blob ID. Semantic search returns matches, not an exhaustive plain-text inventory.
• Corrections, not erasure. Replacing a memory retires its old metadata from recall; it does not promise immediate destruction of an already published Walrus blob.
• Managed custody. The current MemWal account and relayer-managed encryption are application-side infrastructure, not individual wallet custody or user-held encryption keys.
• No verified live bookings. Anghkooey does not claim hotel inventory, current prices, reservations, or integrations it cannot verify.
• No cross-device web recovery yet. Guest browser sessions are convenient but should not be mistaken for a full account-recovery system.
• iMessage is in testing. Public contact details will appear only when a supported public channel is available.

Do not publish other users' memory contents, private IDs, or unredacted receipts in demos or issues without their permission.

Deployment

The production architecture uses separate hosts for web and messaging:

• Web: Vercel deployment guide. Set server-only environment variables, use WEB_BASE_URL with your public HTTPS domain, and verify /api/health plus actual chat behavior. Disable deployment protection for the public production domain before inviting users or judges.
• Worker: Photon deployment guide. Use a persistent systemd or container process; verify readiness and real message replies. Keep exactly one active consumer.

The web app being built successfully does not by itself prove the messaging worker is running. Conversely, worker readiness is not a substitute for a live Telegram/iMessage test.

Project documentation

Document	What it covers
Product requirements	User journeys, intended experience, acceptance criteria
Technical requirements	Architecture contracts, security, memory semantics
System architecture	Data flows and trust boundaries
Brand messaging	Positioning, UX language, responsible claims
Design system	Typography, palette, motion, visual patterns
Web deployment	Vercel and API configuration
Photon deployment	Worker hosting and secure channel linking
Backend status	Implementation notes and verified backend milestones

License and assets

The original software source code in this repository is made available under the MIT License — see the license text for terms and warranty disclaimer.

Brand marks, the Anghkooey name, original artwork, ribbon imagery, screenshot/video material, and bundled fonts are not granted a separate reuse license merely by the software's MIT license. Their use or redistribution depends on ownership and the terms of their respective rights holders. Third-party libraries retain their own licenses. If you fork the code, use your own branding unless you have permission to use these assets.

---

Anghkooey · Remember the preference. Preserve the reason.
Built by Devendurance · © 2026

Back to top