#170 - P2 — RAGE Android Prolog/ZeroMQ/NDK/WASM feasibility bakeoff and architecture decision - nsaspy/zara

lost-rob0t commented

2026-08-22 21:55:09 +00:00

(Migrated from github.com)

Parent epic: #152
Depends on: #133 before implementation; research may begin only as isolated evidence work after current higher-priority daemon queue is clear.
Integrates with: #150, #132, #130/#131.

Goal

Deeply research and prototype the risky foundations before choosing an Android architecture: embedded Prolog runtime, ZARA/1/ZeroMQ transport, Android build/toolchain, background voice constraints and portable semantic subset.

Required Prolog bakeoff

Evaluate at least SWI-Prolog Android/NDK feasibility, SWI WebAssembly embedding, and credible alternative embeddable Prolog engines. Use current upstream primary sources and minimal spike builds where needed. Compare ABI support, maintenance, license, build reproducibility, JNI/FFI, startup/RSS, threading, cancellation, resource loading, supported predicates/modules, foreign libraries, error semantics, APK size and ability to execute Zara's shared semantic fixtures.

Required transport bakeoff

Research direct libzmq/CURVE/ZAP bindings for Android, maintained Java/Kotlin alternatives such as pure-Java ZeroMQ only if wire/security compatibility is proven, JNI packaging and key management. Do not assume a library named ZeroMQ implements the required CURVE/ZAP semantics. If ZARA/1 transport cannot be preserved safely, document the architecture conflict before any replacement protocol proposal.

Android platform research

current background microphone/foreground-service/wake restrictions;
audio capture/playback/audio focus/Bluetooth behavior;
app launch/open URI/clipboard/notification permission/API restrictions;
keystore strategy for client key material;
network security/pinning implications;
Gradle/SDK/NDK reproducibility with Nix developer workflow;
emulator vs real-device testing.

Deliverables

RAGE log with exact start SHA/issue; primary-source research report; runnable minimal spikes where they answer uncertain questions; decision matrix; explicit selected/rejected architecture with failure modes; portable Prolog subset proposal; Android source/build layout proposal; exact child-gate plan.

Non-goals

No production Android UI/client feature; no second assistant backend; no Prolog-RLM; no silent protocol fork.

Acceptance

There is evidence strong enough to choose the Prolog runtime, transport binding, build architecture and Android device/voice constraints without guessing, including explicit fallback if a preferred option is not viable.

Parent epic: #152 Depends on: #133 before implementation; research may begin only as isolated evidence work after current higher-priority daemon queue is clear. Integrates with: #150, #132, #130/#131. ## Goal Deeply research and prototype the risky foundations before choosing an Android architecture: embedded Prolog runtime, ZARA/1/ZeroMQ transport, Android build/toolchain, background voice constraints and portable semantic subset. ## Required Prolog bakeoff Evaluate at least SWI-Prolog Android/NDK feasibility, SWI WebAssembly embedding, and credible alternative embeddable Prolog engines. Use current upstream primary sources and minimal spike builds where needed. Compare ABI support, maintenance, license, build reproducibility, JNI/FFI, startup/RSS, threading, cancellation, resource loading, supported predicates/modules, foreign libraries, error semantics, APK size and ability to execute Zara's shared semantic fixtures. ## Required transport bakeoff Research direct libzmq/CURVE/ZAP bindings for Android, maintained Java/Kotlin alternatives such as pure-Java ZeroMQ only if wire/security compatibility is proven, JNI packaging and key management. Do not assume a library named ZeroMQ implements the required CURVE/ZAP semantics. If ZARA/1 transport cannot be preserved safely, document the architecture conflict before any replacement protocol proposal. ## Android platform research - current background microphone/foreground-service/wake restrictions; - audio capture/playback/audio focus/Bluetooth behavior; - app launch/open URI/clipboard/notification permission/API restrictions; - keystore strategy for client key material; - network security/pinning implications; - Gradle/SDK/NDK reproducibility with Nix developer workflow; - emulator vs real-device testing. ## Deliverables RAGE log with exact start SHA/issue; primary-source research report; runnable minimal spikes where they answer uncertain questions; decision matrix; explicit selected/rejected architecture with failure modes; portable Prolog subset proposal; Android source/build layout proposal; exact child-gate plan. ## Non-goals No production Android UI/client feature; no second assistant backend; no Prolog-RLM; no silent protocol fork. ## Acceptance There is evidence strong enough to choose the Prolog runtime, transport binding, build architecture and Android device/voice constraints without guessing, including explicit fallback if a preferred option is not viable.