Skip to content

Wire conversations CLI to cloud API (self_hosted storage)#13

Merged
andrei-hasna merged 1 commit into
mainfrom
wire/cloud-self-hosted-storage
Jul 7, 2026
Merged

Wire conversations CLI to cloud API (self_hosted storage)#13
andrei-hasna merged 1 commit into
mainfrom
wire/cloud-self-hosted-storage

Conversation

@andrei-hasna

Copy link
Copy Markdown
Contributor

Routes message CRUD to https://conversations.hasna.xyz/v1 (bearer key) when mode=self_hosted and HASNA_CONVERSATIONS_API_URL+HASNA_CONVERSATIONS_API_KEY are set; falls back to local SQLite otherwise (unset vars or mode=local reverts). No DSN on the client.

Conversations is a coordination store: this wiring is OFF by default and fully reversible; it changes no fleet default.

  • New src/lib/cloud-store.ts resolver over the @hasna/contracts HTTP storage client (auto-implies self_hosted when URL+key present so the fleet flip's 2-var output activates cloud).
  • CLI send/show/reply/delete routed (POST/GET/DELETE /v1/messages, unwrapping the {message} envelope; delete passes the required from).
  • Unit tests (9) cover env resolution + routed CRUD against a mocked API.
  • Proven with an installed CLI: env set -> send/show/delete hit the real cloud (verified independently via curl); unset -> local, absent from cloud.

Wire the CLI (`send`, `show`, `reply`, `delete`) through a new
cloud-store resolver that uses the @hasna/contracts HTTP storage client
when mode=self_hosted and HASNA_CONVERSATIONS_API_URL +
HASNA_CONVERSATIONS_API_KEY are set. Routed reads/writes go to
https://conversations.hasna.xyz/v1 with the bearer key; no DSN on the
client. Unset the vars (or mode=local) to revert to the local SQLite
store — off by default, fully reversible (conversations is a
coordination store; this changes no fleet default). Bumps
@hasna/contracts to ^0.5.0.
@andrei-hasna
andrei-hasna merged commit 6bb5e05 into main Jul 7, 2026
andrei-hasna added a commit that referenced this pull request Jul 7, 2026
…ildable)

HEAD bumped @hasna/contracts to ^0.5.0 (for the client cloud-store path added
in #13) but never regenerated bun.lock, which still pins 0.4.1 — so
`bun install --frozen-lockfile` (the ECS Docker build) cannot resolve and the
image is unbuildable.

The serve process imports only @hasna/contracts/auth (present in 0.4.1) and the
vendored storage-kit (self-contained, KIT_VERSION 0.4.1); it never imports the
client-only cloud-store.ts. The deployed prod image already runs 0.4.1 auth, so
existing API keys stay valid. Pinning to ^0.4.1 restores a coherent, buildable
state for the server deploy.

The client cloud-store.ts (which needs contracts 0.5.x `client/storage`) is part
of the separate client-flip workstream: it will move to 0.5.x once contracts
0.5.x is published and the lockfile regenerated.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant