manimani

Choose the policy — the app does the work. manimani is a local-first, keyboard-driven triage app for mail and messages: every decision appends to an auditable Decision Ledger. manimani.cloud serves that same ledger at the edge.

Get the appAPI referencellms.txt

One ledger, local first. The OSS desktop/CLI app runs standalone on a local store — decisions land in JSONL, one decision = one git commit. Connect it to the cloud and the same Decision Ledger is served from this edge Worker: multi-device, durable, same app logic.

How manimani works

Triage, not busywork

Per message you pick only the policy — reply, todo, waiting, done, archive, unsubscribe. Labels, archiving, and LLM reply drafts are done for you.

Keyboard-driven

Linear-like UX: j/k to move, 1–6 for the policy, Enter to confirm, u to undo.

Auditable by design

Every decision is appended to the Decision Ledger. Locally that is JSONL plus a git commit per decision — you can always trace what was handled, when, and how.

Cloud = the same ledger

cloud-manimani is the externally-published API: the ledger, inbox, and rules served from a Cloudflare Worker at manimani.cloud.

API

Everything under manimani.cloud except this page is a JSON API. The deployed route table:

MethodPathWhat it does
GET/healthliveness probe
GET/inboxpending items awaiting a decision
PUT/inbox/<id>upsert an inbox item (body = item)
POST/decisionsappend a triage decision (body = decision)
GET/decisions?since=<seq>the Decision Ledger past a cursor
GET/rulestriage rules
PUT/rules/<id>upsert a triage rule (body = rule)
POST/telemetry/installopt-in anonymous install ping
GET/metricsread-only conversion aggregation

Requests and responses are JSON. Anything else returns a JSON 404.

Try it

# liveness
curl https://manimani.cloud/health
# → {"ok":true,"service":"cloud-manimani"}

# read the Decision Ledger past a cursor
curl "https://manimani.cloud/decisions?since=0"

# append a triage decision (the body is the decision map, appended as-is)
curl -X POST https://manimani.cloud/decisions \
  -H "content-type: application/json" \
  -d '{"item-id":"msg-123","policy":"reply_llm"}'

# opt-in anonymous install ping (device-id required; only
# device-id/version/ts are persisted — everything else is dropped)
curl -X POST https://manimani.cloud/telemetry/install \
  -H "content-type: application/json" \
  -d '{"device-id":"a1b2c3","version":"0.1.0"}'

# read-only conversion metrics
curl https://manimani.cloud/metrics

Privacy — local-first, non-negotiable

Opt-out by default

A stock local install emits no telemetry. The install ping is sent only if you explicitly opt in.

Anonymous device-id only

The ping carries a self-generated device-id plus an optional app version and timestamp — nothing else.

Never the ledger

The telemetry route persists only device-id/version/ts and drops the rest of the body — Decision-Ledger content, message bodies, addresses, or any PII can never leak into the cloud, even from a mis-sending client.

Status

  • Interim storage: the ledger/inbox/rules currently live in the Worker's own KV while the kotobase.net PDS surface this API is designed for is finished upstream (net-kotobase#153). Removing one binding flips the Worker back to the kotobase path.
  • Single cloud account today: the Worker authenticates with one shared credential; per-user DID signup is the designed seam, not yet built.
  • Agent inference not deployed: the cloud-murakumo inference seam is interface-only; no live route calls it.
  • No pricing, no billing: the paid funnel stays at 0 by design until a billing rail exists — pricing is an open human decision.
  • Proposals/reviews gate: a proposal/review event-log surface exists in the JVM-tested portable core but is not yet wired into the deployed Worker.

Docs & links