Files
KamadoPool/README.md
T
satoshi 82941939e5 Phase 4: embed UI into kamado-api binary
The production image is now a single Go binary that serves both the
JSON/WebSocket API under /api and the Svelte dashboard at /.

- New internal/webui package embeds a dist/ subdir via //go:embed.
  A placeholder index.html is committed so `go build` works on a
  fresh checkout; anything else in dist/ is regenerated per build
  and gitignored.

- httpapi.Server.Handler mounts the embed.FS at / with SPA-style
  fallback: unknown non-/api paths serve index.html so client-side
  routes survive a reload. /api/* is carved out explicitly so POSTs
  or typos never accidentally shadow API semantics with HTML.

- api/Dockerfile grows a node:22 builder stage that runs
  `npm ci && npm run build`, and the Go stage copies ui/dist/ into
  internal/webui/dist/ before `go build`. Build context moves to
  the repo root (docker-compose + `make api` both updated) so the
  Dockerfile can see both api/ and ui/.

With this in place, `make up` brings the whole stack online at
http://localhost:8080 — API under /api, dashboard at /. The Vite
dev server on :5173 with the /api proxy is still available via
`make ui-dev` for hot-reload development.
2026-04-13 03:15:36 +03:00

83 lines
4.4 KiB
Markdown

# Kamado Pool
A modern, feature-complete solo Bitcoin mining pool built on a patched fork of CKPool, with a real-time web dashboard and a Go-based API middleware that surfaces everything CKPool knows.
## Why Kamado?
Existing CKPool-based solutions (like Bassin for Umbrel) read only a handful of periodic stats files and miss most of CKPool's rich data. Kamado talks directly to CKPool's Unix socket API to expose:
- Real-time per-client data: hashrate, difficulty, user agent, hardware detection
- Full block-found history with height, hash, reward, and solving worker
- Per-worker and per-client best share tracking (current + all-time)
- Network difficulty, pool efficiency, expected time to block
- Live dashboard updates via WebSocket (no 60-second file polls)
## Architecture
```
┌────────────────────────────────────────────────────┐
│ ckpool-solo (C) ──Unix socket──► kamado-api (Go) │
│ ports: 3333 ports: 80 │
│ │
│ ▲ stratum ▲ HTTP/WS │
│ │ │ │
│ Miners Browser │
│ │
│ bitcoind ◄──── RPC + ZMQ ────── ckpool + kamado-api│
└────────────────────────────────────────────────────┘
```
Three main components:
| Component | Language | Purpose |
| -------------- | -------- | -------------------------------------------------- |
| `ckpool/` | C | Stratum server, share validation, block submission |
| `api/` | Go | Socket client, REST/WebSocket API, persistence |
| `ui/` | Svelte | Real-time dashboard |
## Phases
- [x] **Phase 1** — Fork & fix CKPool, build infrastructure
- [~] **Phase 2** — Go API middleware
- [x] Phase 2a: CKPool socket client, bitcoind RPC, state aggregator, REST API
- [x] Phase 2b: CKPool log tailer, block history, stdlib WebSocket push
- [ ] Phase 2b.5: ZMQ block notifier, SQLite persistence (deferred until s9pk repo exists — need real Go build env for new deps)
- [x] ckpool patch 0001: expose `bestever` in runtime socket JSON so the UI can show "this round" and "all-time" best share side by side
- [~] **Phase 3** — Svelte UI dashboard (skeleton: header, pool overview, miners table, blocks, best shares leaderboard; live WS updates)
- [x] **Phase 4** — Monorepo Docker build: `kamado-api` embeds `ui/dist` via `//go:embed` and serves it at `/`. The api Dockerfile has a node stage that builds the UI before the Go stage embeds and builds the binary; docker-compose uses the repo root as build context so both `api/` and `ui/` are visible.
- [ ] **Phase 5** — Testing (regtest, testnet4), polish
## Quick start (dev)
```sh
cp .env.example .env # set POOL_BTCADDRESS and bitcoind creds
make up # build + start ckpool + api
curl localhost:8080/api/health
curl localhost:8080/api/pool
```
REST endpoints:
| Route | Returns |
| -------------------- | ----------------------------------------------------------- |
| `GET /api/health` | CKPool + bitcoind health |
| `GET /api/pool` | Pool stats + derived hashrate windows + chain info |
| `GET /api/users` | All users from `users` socket command |
| `GET /api/workers` | All workers from `workers` socket command |
| `GET /api/clients` | All connected stratum sessions (useragent, IP, diff) |
| `GET /api/blocks` | Recent solved blocks (in-memory ring, SQLite in Phase 2b.5) |
| `GET /api/snapshot` | Full merged snapshot (everything) |
| `GET /api/ws` | WebSocket push: full snapshot on every refresh + on solve |
StartOS packaging lives in a separate repository.
## Upstream
CKPool by Con Kolivas: https://bitbucket.org/ckolivas/ckpool
Pinned commit: see [ckpool/CKPOOL_COMMIT](ckpool/CKPOOL_COMMIT)
## License
GPL-3.0. CKPool itself is distributed under GPL-3.