February 13, 2026 5 min read Python fork

wifi densepose

Abstract

Production-ready implementation of InvisPose - a revolutionary WiFi-based dense human pose estimation system that enables real-time full-body tracking through walls using commodity mesh routers

Forked from ruvnet/RuView

The Problem

Deploying Wi‑Fi‑based human‑pose estimation in production requires a pipeline that can ingest raw CSI data, run high‑throughput signal processing, expose a low‑latency API, and optionally stream results to a web UI. Existing research prototypes are single‑language and lack containerisation, CI, or robust error handling, making them fragile for on‑prem or edge deployments.

What This Does

The repo ships five self‑contained projects that together cover the full stack:

v1/ – a Python FastAPI service (v1/src/services/pose_service.py) that wraps the original CSI‑processing code, adds authentication, rate‑limiting, and WebSocket streaming (v1/src/api/websocket/connection_manager.py).
rust-port/ – a high‑performance Rust implementation (rust-port/wifi-densepose-rs/crates/wifi-densepose-cli/src/main.rs) that reproduces the signal pipeline with µ‑second latency and provides a CLI (wifi-densepose-cli) and a library (wifi-densepose-api).
ui/ – a React front‑end (e.g., ui/components/LiveDemoTab.js) that connects to the WebSocket endpoint and renders pose skeletons in the browser.
references/ – minimal demo scripts (references/app.js, references/index.html) that launch the FastAPI server and the UI together for quick validation.
.claude/ – a collection of analysis agents and documentation assets; not part of the runtime but useful for internal research.

Common techniques include CSI preprocessing, phase unwrapping, feature extraction, and deep‑learning inference (Python) or deterministic signal math (Rust). The Rust port re‑exports the same public API, so the Python service can optionally load the compiled library via ctypes (not shown in the tree but referenced in v1/src/services/pose_service.py).

How It Is Wired

Execution begins at the entry point you invoke:

Rust CLI – cargo run --release in rust-port/wifi-densepose-rs. main.rs parses CLI args, calls wifi_densepose_cli::run(), which forwards to wifi_densepose_api::process_csi() (defined in lib.rs). The API crate exposes process_csi, extract_features, and detect_pose. Tests (rust-port/wifi-densepose-rs/crates/wifi-densepose-cli/tests/) verify each stage.

Python FastAPI – uvicorn v1.src.main:app --host 0.0.0.0 --port 8000 (the app object is created in v1/src/main.py). Incoming HTTP requests hit the router defined in v1/src/api/routers/pose.py, which calls pose_service.process() in v1/src/services/pose_service.py. That function either invokes the pure‑Python pipeline (v1/src/services/signal.py) or loads the Rust library via ctypes.CDLL and calls process_csi. The WebSocket manager (v1/src/api/websocket/connection_manager.py) broadcasts pose frames to any client that opened ws://…/ws/pose.

React UI – ui/app (bundled by the Dockerfile) opens a WebSocket to /ws/pose. Incoming JSON frames are handed to ui/services/pose.service (most‑connected module) which updates the LiveDemoTab canvas. The UI does not perform signal work; it only visualises the stream.

The internal call graph shows a clear funnel: ui/app → ui/services/websocket.service → FastAPI → pose_service → (Rust lib). The most connected module is ui/services/pose.service (5 incoming, 3 outgoing imports). No circular dependencies were detected, keeping the blast radius limited to these hubs.

How To Use It

# Clone the repository (preserve the exact URL)
git clone https://github.com/moses-y/wifi-densepose.git
cd wifi-densepose

# Build and run the Rust CLI (quick sanity check)
cd rust-port/wifi-densepose-rs
cargo build --release
cargo test --workspace          # 107 tests, 100% coverage reported
cargo run --release -- --input samples/csi.bin   # example CLI usage

# Start the Python service in a container (Dockerfile present)
docker build -t wifi-densepose .
docker run -p 8000:8000 wifi-densepose   # launches FastAPI + WebSocket

# In a separate terminal, launch the demo UI
docker exec -it $(docker ps -qf "ancestor=wifi-densepose") npm start   # runs UI from /ui
# Open http://localhost:3000 (or the port exposed by the UI) to see live pose overlay.

Configuration – The FastAPI service reads PYTHONPATH and optional RUST_LIB_PATH environment variables (set automatically by the Dockerfile). No secret files are required for a local run; production deployment must supply the secrets referenced in .github/workflows/cd.yml (e.g., KUBE_CONFIG_DATA).

Real‑World Use

A warehouse operator could deploy the Docker image on an edge gateway. The gateway streams CSI from commodity mesh routers to the FastAPI service, which forwards pose updates over WebSocket to a monitoring dashboard (the React UI). An alert pipeline could subscribe to the same WebSocket, detect falls via the pose_service.detect_fall() helper, and push notifications to Slack (the Slack webhook URL is stored as a secret in the CI workflow).

# Example: subscribe to pose stream and trigger an alert
import websockets, json, os

async def monitor():
    async with websockets.connect("ws://gateway:8000/ws/pose") as ws:
        async for msg in ws:
            data = json.loads(msg)
            if data["fall"]:
                # POST to Slack (secret injected at runtime)
                await aiohttp.post(os.getenv("SLACK_WEBHOOK_URL"), json={"text": "Fall detected"})

Code Health & Issues

Critical – Secrets (KUBE_CONFIG_DATA, SLACK_WEBHOOK_URL) are stored in .github/workflows/cd.yml; a malicious PR could exfiltrate them. Fix: move secret‑using steps to a workflow_run job or require reviewer approval.
High – GitHub Actions are not pinned to commit SHAs; tag drift could expose the same secrets. Fix: replace @vN with full SHA.
High – No lockfile for Python (pyproject.toml without poetry.lock/requirements.txt lock). Fix: generate and commit the lockfile.
High – continue-on-error on correctness steps in CI (.github/workflows/ci.yml). Fix: remove or isolate advisory steps.
Medium – Broad exception handling in several Python modules (v1/src/api/websocket/connection_manager.py, etc.). Fix: catch specific exceptions and log others.
Medium – Empty catch {} in .claude/helpers/metrics-db.mjs. Fix: log or rethrow.
Medium – Oversized UI components (ui/components/LiveDemoTab.js, PoseDetectionCanvas.js, SettingsPanel.js). Fix: split into smaller, responsibility‑focused modules.
Medium – Unpinned Docker base image (python:3.11-slim). Fix: use digest.
Low – No job timeouts in CI workflows; could cause overlapping runs. Fix: add timeout-minutes.
Low – Repository lacks formatting conventions (.editorconfig, etc.). Fix: add standard config files.

The Bottom Line

The repo delivers a complete, containerised stack for Wi‑Fi‑based dense pose estimation, with a high‑performance Rust core and a Python API that can be extended or replaced. Production readiness is hampered by serious secret‑handling lapses and several maintainability issues (deep nesting, duplicated helpers, oversized UI files). Teams that need a proven Wi‑Fi pose pipeline can adopt the Rust core quickly, but must address the highlighted security and hygiene problems before exposing the system in a live environment.

What the analyser found

Deployment readiness

6/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

605 files

Markdown295
Python100
Rust67
Shell31
JavaScript23
YAML18

ReactDjangoFlaskExpressDockerKubernetesTerraform

Module dependencies

The 10 most depended-upon modules of 121, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_ui_config_api_config["api.config"] n1_ui_services_pose_service["pose.service"] n2_ui_services_api_service["api.service"] n3_i_services_websocket_service["websocket.service"] n4_ui_services_health_service["health.service"] n5_ui_utils_backend_detector["backend-detector"] n6_ui_components_TabManager["TabManager"] n7_1_src_hardware_csi_extractor["csi_extractor"] n8_ui_components_LiveDemoTab["LiveDemoTab"] n9_mponents_PoseDetectionCanvas["PoseDetectionCanvas"] n8_ui_components_LiveDemoTab --> n9_mponents_PoseDetectionCanvas n8_ui_components_LiveDemoTab --> n1_ui_services_pose_service n8_ui_components_LiveDemoTab --> n3_i_services_websocket_service n9_mponents_PoseDetectionCanvas --> n1_ui_services_pose_service n2_ui_services_api_service --> n0_ui_config_api_config n2_ui_services_api_service --> n5_ui_utils_backend_detector n4_ui_services_health_service --> n0_ui_config_api_config n4_ui_services_health_service --> n2_ui_services_api_service n1_ui_services_pose_service --> n0_ui_config_api_config n1_ui_services_pose_service --> n2_ui_services_api_service n1_ui_services_pose_service --> n3_i_services_websocket_service n3_i_services_websocket_service --> n0_ui_config_api_config n3_i_services_websocket_service --> n5_ui_utils_backend_detector n5_ui_utils_backend_detector --> n0_ui_config_api_config

Dependencies

21 of 101 declared dependencies are a major version behind. Resolved 55 of 101 against the registry.

Package	Declared	Latest	Behind
`websockets`	>=10.4	17.0.1	7 major
`redis`	>=5.0.0	8.1.0	3 major
`structlog`	>=23.2.0	26.1.0	3 major
`pytest-cov`	>=4.1.0	7.1.0	3 major
`black`	>=23.9.0	26.5.1	3 major
`isort`	>=5.12.0	8.0.1	3 major
`pillow`	>=10.0.0	12.3.0	2 major
`paramiko`	>=3.3.0	5.0.0	2 major

Findings

LowSecret-shaped paths present; the code-health audit confirms or clears them k8s/secrets.yaml

Open in Code Brain → See its neighbourhood →

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

critical1

high4

medium4

low2

Keep secrets out of workflows a fork can triggercritical4 occurrences

.github/workflows/cd.yml

KUBE_CONFIG_DATA, KUBE_CONFIG_DATA_STAGING, KUBE_CONFIG_DATA_PRODUCTION, SLACK_WEBHOOK_URL (publish or cloud scope)

Contributor-controlled input reaches a job holding a publish token or cloud credential, so a pull request becomes credential exfiltration.

Fix: Move secret-using steps into a workflow_run job that never checks out pull request code, or gate on an environment with required reviewers.

Pin third-party GitHub Actions to a commit SHAhigh18 occurrences

.github/workflows

azure/setup-kubectl@v3, 8398a7/action-slack@v3, codecov/codecov-action@v3, docker/setup-buildx-action@v3

A tag can be moved, so the action running with your token and secrets is whatever its owner last pushed; this is how tj-actions/changed-files leaked secrets from thousands of repos.

Fix: Replace each @vN with the 40-character commit SHA, keep # vN as a comment, and let Dependabot bump the SHAs.

Upgrade the pinned dependency carrying a published advisoryhigh2 occurrences

sqlx@0.7 GHSA-xmrp-424f-vfpx (medium) +1 more

The pinned version is the one that installs, so a published advisory against it describes this deployment rather than a hypothetical one, and the advisory is also a public description of how to exploit it.

Fix: Upgrade to the fixed version named in the advisory, then commit the lockfile.

Commit a lockfile beside the manifesthigh

pyproject.toml

manifest with no lockfile in scope

An unlocked range means the artifact you tested and the artifact you ship can contain different transitive code, so a malicious patch release reaches production with no diff.

Fix: Run the package manager once and commit the generated lockfile.

Remove continue-on-error from steps that gate correctnesshigh

.github/workflows/ci.yml

line 50 on a correctness step

A failing test suite reports a green check, which is precisely the path this audit exists to close.

Fix: Delete continue-on-error, or move a genuinely advisory step into a separate non-required job.

Declare least-privilege permissions for GITHUB_TOKENmedium2 occurrences

.github/workflows/cd.yml

2 workflow(s) declare no permissions, 2 of them reference secrets

With no declaration the token inherits the repository default, so any injected step can push commits or mint releases from inside your own CI.

Fix: Add permissions: contents: read at the top of the workflow and widen per job only where needed.

Enable Dependabot or Renovatemedium

13 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Pin the container base image by digestmedium

Dockerfile

python:3.11-slim

An untagged or mutable base means today's build and last month's contain different libc and a different CVE set, with no record of which shipped.

Fix: Use image:tag@sha256:<digest> and enable Dependabot's docker ecosystem.

Set persist-credentials: false on checkoutmedium

.github/workflows/ci.yml

checkout keeps the token, then dependencies are installed

The token stays in .git/config for every later step, so a malicious postinstall script reads a pushable credential without one ever being passed to it.

Fix: Add with: persist-credentials: false, and pass an explicit token only to the step that pushes.

Set timeout-minutes on the workflow jobslow3 occurrences

.github/workflows/cd.yml

3 workflow(s) declare no job timeout

A wedged step runs to the six-hour platform default, which on a two-hourly schedule means three runs overlap behind it.

Fix: Add timeout-minutes with a realistic bound to each job.

Add the repository convention files this project lackslow3 occurrences

missing .editorconfig, .gitattributes, a formatter config

Without them one contributor's editor writes tabs into a Python file, a shell script commits with CRLF and fails in the container, and a notebook diff is unreviewable.

Fix: Add .editorconfig, .gitattributes with text=auto eol=lf, and a formatter config.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.

View on GitHub All Projects