You open fata.uk
, write a few lines about what is on your mind, and AI finds a stranger whose emotional frequency matches yours. Then it gives you each other’s email and exits. No app. No signup. No database. No chat history.
The entire backend is a single Cloudflare Worker. State lives in GitHub Issues. Here is the flow:
Browser (signal heuristic, ms-level)
→ HMAC-signed POST → Cloudflare Worker
→ BGE-M3 embedding API (1024-dim)
→ AES-256-GCM encrypt → GitHub Issues (encrypted pool)
→ Multi-channel scoring → MMR diversity rerank
→ Match found? → Internal LLM resonance → Resend email
Before any API call, the browser computes four heuristics on the user’s text: length, lexical diversity, sentence count, and concrete detail markers. Score < 0.3? Gentle nudge to write more. Score < 0.15 on the server side? Rejected. This filters out noise before it hits the pool.
Every submission requires solving a SHA-256 PoW challenge (difficulty 16 — ~1-2s on mobile). The solution is verified server-side, and a short-lived submit token (30 min TTL) is issued. Combined with per-IP and per-email rate limits, this makes automated abuse economically unattractive.
The Worker calls SiliconFlow’s BGE-M3 embedding API (1024-dim). If that fails, it falls back to the browser-provided TF-IDF embedding. If both fail, server-side TF-IDF is computed. The original text is discarded after embedding — the vector cannot be reversed back to words.
This is the part I find most fun. Sensitive data (email, embedding, text snippet) is AES-256-GCM encrypted and stored in Cloudflare KV. Only metadata (language, embedding type, key version) goes into the GitHub Issue body. The pool is public but every entry is ciphertext.
The matching engine scores candidates across four channels:
Top candidates are reranked with MMR (Maximum Marginal Relevance) to ensure diversity in the matched pool.
When a match is found, an internal LLM call generates a short resonance paragraph and three icebreaker questions. Both users receive each other’s email via Resend. After that, fata is out of the picture — all further communication happens in the user’s own email client.
HMAC_KEY
(API signing, frontend-visible) ≠ ENCRYPTION_KEY
(data at rest, Worker secret only)/api/hmac-key
endpoint was discovered and abused for LLM proxy spam (3.49 billion tokens in one day). Fixed within hours. All public LLM endpoints deleted. Postmortem in the repo.Every "anonymous chat" product eventually faces the same trust problem: users have to believe the platform when it says it does not read their messages. fata solves this by making it architecturally impossible to read messages — because the messages are not in fata. They are in your Gmail.
Static HTML page (single file)
→ Cloudflare Worker (fata.uk/api/*)
→ GitHub Issues (encrypted pool)
→ Cloudflare KV (sensitive data, 30-day TTL)
→ SiliconFlow BGE-M3 (embedding)
→ SiliconFlow DeepSeek V3 (resonance LLM)
→ Resend (email)
** fata.uk** — open in any browser.
Source: ** github.com/gsailing19/fata** (MIT)
If you have built something with "impossible" architecture — zero servers, zero databases, or a constraint that shaped the product in unexpected ways — I would love to hear about it in the comments.