WeChat Parity Map — Kimosabe.AI Baseline
Source: WeChat Feature Inventory v0.1 — Documentary Reconnaissance (Haight + Novum, 2026-05-09).
Purpose: take every organ of WeChat named in the inventory, map it against
what Kimosabe ships today, and label each one. This is the baseline we
plan from — not a roadmap commitment. A "📅 Planned" line here is a
candidate, not a promise. The ❌ Out of scope lines are the doctrine.
Last sync: 2026-08-25. Owner: Donald + Lovable.
Legend
| Symbol |
Meaning |
| ✅ |
Shipped — live in Kimosabe today |
| 🟡 |
Partial — some of the organ exists; gaps listed |
| 🔄 |
Comparable / inverted — we have the function but architected the opposite way (this is usually the point) |
| 📅 |
Planned — already on the roadmap (Phase 2–6) |
| 🤔 |
Under consideration — surfaced by the inventory, not yet decided |
| ❌ |
Out of scope, forever — deliberate refusal, doctrinally locked |
| 🚫 |
N/A — China-specific, civic-system-specific, or otherwise non-portable |
§1 — Founding pattern & growth mechanics
| WeChat organ |
Kimosabe state |
Notes |
| Skunkworks origin (7 engineers) |
🔄 |
One founder + AI agents. Same shape, smaller crew. |
| First-growth feature that removes friction for an ignored demographic (voice messaging for older Chinese users) |
🤔 |
Open question. What is our voice-message moment? Candidate: the Recovery Key paper card for Americans who don't trust the cloud. Needs a named owner. |
| Cultural-ritual viral hack (red envelope → payment onboarding) |
🤔 |
Open question. Inventory §1.6 names this as the playbook. No Kimosabe equivalent yet. Memorial Day 2026 (E-002) is the first test slot. |
| QR code as universal handshake |
📅 |
Phase 2: each user has an @handle + invite link; QR-card export is a small lift. Worth pulling forward. |
| Algorithmic discovery feed (Channels) |
❌ |
Friend-graph only. We will not deviate. (Inventory §1.8 itself reads this as WeChat's tell.) |
| AI-native developer tooling (2025 wave) |
🟡 |
Agent SDK Preview compiles + runs against the 1:1 protocol. No customer-facing AI surface yet. |
§2 — Ownership, corporate structure, legal geography
| WeChat organ |
Kimosabe state |
Notes |
| Single corporate parent governs + profits + audits + complies with state |
❌ |
The whole reason this project exists. No-Conflicts Standard (P-002) makes this structurally impossible. |
| Domestic/international split (Weixin vs WeChat) with porous surveillance leak |
🚫 |
We do not run a domestic captive variant. One product, one law (US). |
| Real-name registration chained to telecom |
❌ |
No phone number ever. Email + handle. |
| Publicly traded holdco |
🤔 |
Future ownership form (co-op? PBC? trust?) is a Move-2 question, not decided. |
§3 — Identity & trust substrate
| WeChat organ |
Kimosabe state |
Notes |
| Account = phone + national ID |
❌ |
Email + chosen handle. No phone, no real-name. |
| Single identity across every service |
🟡 |
Today: one account = messaging only. The architectural slot is there (ECDH keypair + wrapped private key); future Mini-Program-shaped tools would inherit it. |
| KYC/AML for payments |
🤔 |
Only relevant when P2P payments arrive (Phase 5). Will require a regulated processor; doctrine is we never custody funds. |
| Civic identity absorption (social security card, e-ID) |
❌ |
We are not a civic ID system. We can attest to external identities (Phase 3 federated attestation) without absorbing them. |
| Social Credit / redlist mechanic |
🔄 |
Inventory Doc-003: redlist is portable, positive-only, voluntary. TER + Founders Coin tier system are already redlist-shaped. Memorial Day 2026 is the transferability test. |
| Blacklist / punitive scoring |
❌ |
Never. |
§4 — Mini Programs (the architectural heart)
| WeChat organ |
Kimosabe state |
Notes |
| Sandboxed app runtime inside the host |
📅 |
Phase 5 "mini-app container with strict permissions." Inventory §4 is the single most important section for our architecture; pull this forward in planning. |
| Standardized frontend stack (WXML/WXSS/JS) |
🤔 |
If we build this, the runtime must be open and portable (markdown/YAML node format already points this way). Otherwise we reinvent the captive-substrate failure mode. |
| Containerized isolation between programs |
📅 |
Same Phase 5 slot. |
| QR / chat-share / search / geofence invocation |
📅 |
QR + chat-share are cheap; geofence is a separate decision. |
| Pinned home page of frequently-used programs |
📅 |
UI affordance, trivial once runtime exists. |
| 30-40% of native cost, 4-6 week build cycle |
🔄 |
Our equivalent is the Lovable build loop itself. Already true. |
| Host takes a small slice from many federated services |
🤔 |
Business-model question for Move 2. Doctrine: settlement layer is not a profit center (see §5). |
| Developer locked to proprietary runtime |
❌ |
Hard refusal. Whatever we ship must export cleanly. |
§5 — Payments / settlement
| WeChat organ |
Kimosabe state |
Notes |
| In-app peer-to-peer transfers |
📅 |
Phase 5: P2P payments via regulated processor (Stripe / Paddle). |
| QR-code merchant payments |
📅 |
Phase 5. |
| 0.1% transaction fee, free P2P |
🔄 |
Doctrine: settlement is loss-leader infrastructure. Matches inventory §5.4 read. |
| Float-income on customer wallet balances |
❌ |
We never custody funds. |
| Four-class token separation (governance/utility/settlement/reputation) |
🔄 |
This is our architecture; WeChat is the negative example. Already locked in the Codex. |
§6 — Communication & social layers
| WeChat organ |
Kimosabe state |
Notes |
| 1:1 text messaging |
✅ |
E2EE (ECDH → HKDF → AES-GCM-256). |
| Voice messages |
📅 |
Phase 2 voice notes (HPKE envelope, RFC 9180). |
| Voice/video calls |
🤔 |
Not yet on roadmap. Candidate for Phase 2.5. |
| Group chats (~500 members) |
📅 |
Phase 2 via MLS (RFC 9420). |
| File / image sharing |
🟡 |
Encrypted images ✅. Generic file attachments not yet. |
| Stickers |
🤔 |
Low priority. Trivial once attachments exist. |
| Location sharing |
🤔 |
Privacy-sensitive; needs design (ephemeral-only, never logged server-side). |
| Translation in-line |
🤔 |
Could be a Lovable AI Gateway call, client-side only. |
| Transport-encrypted but server-readable |
❌ |
E2EE only. The whole point. |
| Moments (friend-graph-only feed, friend-of-friend visibility) |
📅 |
Phase 5 "Moments-style feed, server-blind, scoped to your contact graph." Inventory §1.3 explicitly endorses this design; one of the few WeChat patterns we keep. |
| Two-ads-per-day discipline |
❌ |
Zero ads. Ever. |
| Subscription Official Accounts (1 article/day) |
🤔 |
Maps to a future "publisher" role. Phase 5-ish. |
| Service Official Accounts (4 pushes/month + payments) |
🤔 |
Same slot as Mini Programs; revisit when sandbox runtime ships. |
| Enterprise / WeCom variant |
🤔 |
A Kimosabe-for-Teams variant is plausible Phase 4-5. Not committed. |
| Algorithmic short-video Channels |
❌ |
See §1. |
§7 — Backend & operational scale
| WeChat organ |
Kimosabe state |
Notes |
| Proprietary Paxos-based strong-consistency store |
🔄 |
We use Postgres (Lovable Cloud) with RLS. Different scale, same correctness posture. |
| Microservice / API-gateway topology |
🟡 |
Edge functions + server functions. Adequate for Phase 1-3. |
| 10B msgs/day, 100B Moments interactions/day |
🚫 |
Not our scale problem yet; revisit if Cohort 001 → Cohort N grows. |
| pg_cron-style scheduled cleanup |
✅ |
Disappearing-message purge runs server-side. |
§8 — What WeChat does that we will never do
(These are already in FEATURES.md §❌. Listed here so the parity map is complete.)
- ❌ Server-side message search
- ❌ Cloud backup we control
- ❌ Lawful-intercept backdoor / key escrow / ghost user
- ❌ Plaintext push notifications
- ❌ Plaintext content in logs/metrics/analytics
- ❌ Phone-number requirement
- ❌ Address-book / contact-graph upload
- ❌ Real-name policy
- ❌ Selling, sharing, or "anonymizing-and-selling" user data
- ❌ Ads, sponsored messages, dark patterns, streak guilt
- ❌ Tracking pixels / 3rd-party analytics / fingerprinting
- ❌ Captive runtime that can't export
Tally
| State |
Count |
Read |
| ✅ Shipped |
3 |
Messaging core + encrypted images + server-side TTL purge. The substrate is real. |
| 🟡 Partial |
5 |
Identity slot, file attachments, microservices, agent SDK, a11y. Each has a known next step. |
| 🔄 Comparable / inverted |
7 |
Where we already match the function but architected the inverse. These are the wins. |
| 📅 Planned |
9 |
Mostly Phase 2 (groups, voice, push, MLS) and Phase 5 (mini-apps, payments, Moments). |
| 🤔 Under consideration |
13 |
The actual planning surface for the next two Moves. |
| ❌ Out of scope |
14 |
Doctrine. Don't re-litigate. |
| 🚫 N/A |
2 |
China-specific. |
What this baseline tells us to do next
- Pick the "voice-message moment." §1 has an open question with no owner. That's the single highest-leverage decision in this map. Candidate: the Recovery Key as a paper-first artifact — the thing that converts Americans who don't trust the cloud.
- Pick the "red envelope ritual." §1.6 is the second open question. Memorial Day 2026 (E-002) is the slot; we need a ritual proposal before then.
- Resolve the 13 🤔 items into either 📅 or ❌. That is the work of Move 2 (Source Intelligence) and Move 4 (SRS).
- Pull the Mini-Program-shaped runtime decision forward. §4 is the most important architectural section in the whole inventory. The current Phase 5 placement is too late if county-level operators show up sooner.
- Lock the redlist-only, positive-only governance posture as a written ADR. Inventory §3.4 + Doc-003 already imply it; an ADR makes it harder to reverse under pressure.
This map is derived. When a 📅 ships, move it to ✅ in FEATURES.md first, then mirror here. When a 🤔 resolves, write the ADR first, then update both files.
