zooqueenandHanzo Dev b0d2181f92 sync: the forge being ahead of GitHub is not a divergence
ff-main has been red every ten minutes. Eleven consecutive failures in the
hour I read it, and not one of them a divergence: the branch asked only
"is LOCAL an ancestor of REMOTE" and called every other answer DIVERGED,
so the forge simply being AHEAD of GitHub took the loud-failure path.

That is the normal state after every native push, and it is not brief --
the push-mirror is sync_on_commit with an 8h floor, so one commit can
produce up to 48 false alarms before GitHub catches up.

The cost is not the noise. A job that is always red cannot report the one
thing it exists to report, and this job's whole value is refusing to
force-push a real divergence. The loud failure is worth keeping only if it
is rare.

Four sibling repos (app, git, hanzo.ai, iam) already carry exactly this
two-direction check; id had the stale copy. Same logic, same order --
this is convergence onto the estate's answer, not a new one. HIPs,
mirrors and python-sdk are still stale and are being fixed with it.

Exercised against real git ancestry, all four states:

  state          old              new
  equal          in-sync(0)       in-sync(0)
  github-ahead   fast-forward(0)  fast-forward(0)
  native-ahead   DIVERGED(1)      native-ahead(0)   <- the fix
  diverged       DIVERGED(1)      DIVERGED(1)       <- alarm preserved

One row moves. The genuine-divergence alarm still fires, which is what
keeps this a fix rather than a mute button.

Co-authored-by: Hanzo Dev <[email protected]>
2026-08-06 15:55:12 -07:00
2026-02-14 05:26:48 -08:00
2026-06-28 20:06:13 -07:00

id

@hanzo/id

White-label login + identity verification portal. One Vite SPA, four hosts (hanzo.id, lux.id, zoo.id, pars.id), per-tenant brand resolved from the request hostname at runtime.

Layout

apps/
  web/                Vite + React 19 + @hanzo/gui — the actual SPA
    k8s/              Deployment + Service + Ingress (4 hosts, 4 TLS secrets)
pkgs/
  shared/             @hanzo/id-shared  — TenantConfig + brand resolver
  auth/               @hanzo/id-auth    — composable login/signup/OTP flows
                                          on top of @hanzo/iam SDK
  idv/                @hanzo/id-idv     — pluggable identity verification
                                          (Persona, Onfido, Veriff, stub)
legacy-nextjs/        Frozen — predecessor Next.js implementation. Kept
                     for reference until v0.1.0 ships to production.

Local dev

pnpm install
pnpm dev                 # http://localhost:5173 (defaults to hanzo brand)

To preview a different brand locally, edit /etc/hosts:

127.0.0.1  lux.id zoo.id pars.id

then visit http://lux.id:5173.

Build

pnpm build               # builds apps/web -> dist/
docker build -t ghcr.io/hanzoai/id:0.1.0 .

Adding a brand

  1. Publish or workspace-link the new per-org brand pkg (must ship brand.json at the package root and match the BrandContract shape in pkgs/shared/src/types.ts).
  2. Add a DEFAULT_TENANTS entry in pkgs/shared/src/tenant.ts OR put the override in the runtime catalog (IAM_TENANT_CONFIG_JSON env) so no rebuild is needed.
  3. Add the hostname to apps/web/vite.config.ts::BRAND_PACKAGES (lets dev + build serve /brand/<pkg>/brand.json).
  4. Add the hostname + TLS secret to apps/web/k8s/ingress.yaml.
  5. DNS: CNAME or A record → cluster ingress IP.

That's it — no per-brand Worker, no per-brand image, no per-brand deployment. One binary, four brands.

Plugging an IDV provider

import { registerProvider, createPersonaProvider } from '@hanzo/id-idv'
registerProvider(createPersonaProvider({
  templateId: import.meta.env.VITE_PERSONA_TEMPLATE_ID,
  apiKey: import.meta.env.VITE_PERSONA_API_KEY,
  environment: 'production',
}))

The portal stays unchanged — switching providers is a single registration call at boot.

S
Description
No description provided
Readme MIT
3.7 MiB
Languages
TypeScript 92.1%
CSS 4.5%
JavaScript 2.6%
Dockerfile 0.6%
HTML 0.2%