mirror of
https://github.com/hanzoai/chat.git
synced 2026-09-30 20:51:17 +00:00
Chat sent uploaded-file text to a standalone python rag-api which embedded it via
api.fireworks.ai — a THIRD PARTY — while every other chat path (completions, agents,
code, websearch) already runs on api.hanzo.ai. That was both a second way to do RAG
and customer documents leaving our infrastructure.
hanzoai/ai already owns the canonical surface: its controllers/rag.go declares itself
'the consolidated home of the retired standalone chat-rag-api ... the SINGLE canonical
RAG surface', serving /v1/rag/{embed,query,query-multiple,delete,context} on OUR
embeddings, OUR vector store and OUR search index. The code consolidation had shipped;
the deploy cutover never did. This completes it.
- services/RagClient.js is the ONE client every retrieval call goes through: the
origin resolves exactly as CloudAgentsClient does, and identity is the caller's own
IAM bearer (resolveTenantBearer) + selected org (X-Org-Id) — the same credential the
completion/agent paths forward. The backend derives the owner from that verified
token (requireIndexAuth) and scopes every chunk to it, so a user only reaches their
own org's documents. Chat no longer mints a RAG identity or asserts an owner, and a
request with no forwardable token performs NO call (fail-secure).
- VectorDB embed/delete now speak the native JSON contract and the {status,data}
envelope is unwrapped once, in the client.
Pairs with the org-scoped S3 keys (t/<org>/...): content and its embeddings are now
scoped by the same IAM org, on our own storage.
Tests: 7 new (URL is always the unified backend, IAM bearer forwarded, X-Org-Id
forwarded, multi-file -> query-multiple, no-token -> no call, origin fallback). The
Files/Code failures in this tree are pre-existing on main (21 fail without this change).
Previously-embedded files live in the retired service's store and will need re-upload
to regain retrieval — accepted, per the cutover decision.