PROJECTS

These projects (and more) are available here: www.github.com/shinymonitor

• 25/05/2025: EFPIX
• 05/06/2026: SUBLANQ
• 05/06/2026: FLARE
• 07/09/2025: QMTIK

EFPIX

In a world of growing surveillance, censorship and infrastructure failure, we need protocols that ensure unrestricted communication in the most disconnected and totalitarian environments. EFPIX (Encrypted Flood Protocol for Information eXchange) is a topology-agnostic flood-type relay protocol that also achieves end-to-end encryption, plausible deniability for users, untraceability of messages, spam resistance and other optional features.

Why use EFPIX

Modern messaging platforms, even encrypted ones, depend on centralized infrastructure which makes them vulnerable to:

• Surveillance or takedown
• Infrastructure loss
• Metadata leaks

EFPIX counters this by never requiring a central server but also hiding not only the message content but also sender's and receiver's identities.

Where to use EFPIX

• Disaster zones where network infrastructure was lost
• Authoritarian Regimes for whistleblowing, journalism and activism where communication is surveilled and censored
• Space, research, military, or other remote networks where the existence and maintenance of a server is not feasible
• Broadcasts like emergency rescue calls, disaster warnings, and news distribution
• General-purpose privacy focused applications

What is it designed for

EFPIX is not optimized for high-bandwidth or ultra-low-latency applications. It is best suited for asynchronous and privacy-critical communication such as secure email, file drops, offline messaging and distributed alerts.
"0% performance, 100% security": EFPIX prioritizes anonymity and resilience over speed. You can choose optional features to balance your needs.

GitHub repo: EFPIX, libefpix
Whitepaper: arXiv

SUBLANQ

SUBLANQ is an assembly-like language compiler for the Subleq (Subtract and Branch if Less than or Equal to Zero) architecture. It uses AT&T syntax and compiles down to highly optimized Subleq machine code. It comes with support for variables, pointers, allocations, arithmetic, I/O and control flow and a fast emulator to run the generated binary.

Why subleq?

• Simplicity: An extremely simple CPU design with a minimal transistor count. Great for embedded systems, education and hobbyist manufacturing
• Efficiency: Less power, die space and cycles by eliminating complex instructions, decoding, branch prediction, call stacks, out-of-order execution logic etc.
• Fixed Memory Footprint: Subleq programs and data reside in a unified, constant and predictable memory space.
• Resilience: Ideal candidates for "apocalypse machines" or fantasy consoles where hardware must be understandable, reproducible, and durable.
• Parallelism: A single chip can host a massive array of small and cheap subleq cores.

Port mapped IO

• Why not Memory-Mapped I/O? Complicates the memory controller, "pollutes" the address space which we already dont have enough of and locks I/O to specific hardware configurations.
• Why not Interrupts? Interrupts require complex state-saving logic and additional registers (stack pointers), which violates the OISC minimalism philosophy.
• Port-Mapped I/O: A novel way to add support for port mapped IO while maintaining the simplicity of the Subleq architecture. When the A or B operand refers to the null address (-1 / WORD_MAX), the CPU repurposes the C operand as a Port ID / Device Selector. A is null for input while B is null for output.

GitHub repo: sublanq

FLARE

FLARE (Field Learnable ARbitrary Event) Prediction Engine is a self-supervised closed-loop event prediction algorithm that has automatic online adaptation. It is designed for embedded machine learning applications where the model needs to adapt to changing conditions and event precursors without any prior knowledge or offline training.

Why use FLARE?

• Real time adaptation: In conventional embedded ML, a model is trained offline on a known dataset, deployed as a static artifact and cannot adapt to a new environment.
• No prior knowledge required: FLARE requires no pre-training, labeling or prior knowledge of the usage.
• Suitable for any predictive task: Its simple and efficient design makes it applicable to a wide range of predictive tasks like process control.

How does it work?

FLARE maintains a rolling buffer of the inputs called the context. At any moment, the networks input is a slice of that buffer called the window. Every frame the engine makes an inference based on the most recent window. When its output crosses a confidence threshold, it fires the prediction (ahead of the event by however many samples the rollback was set to). Then it waits to see if its prediction was correct or not. If it was incorrect (false positive or false negative), it trains itself on the precursor window.

GitHub repo: flare

QMTIK

QMTIK is a minimal, dependency-free implementation of a quantized neural network designed for embedded systems and resource-constrained environments. By using integers for both weights and activations and heap-less memory, it can deploy machine learning on devices with just a few kilobytes of memory.

Why Quantization and QAT

Normally, neural networks are trained and run with 32-bit floating point weights and activations. But this makes running the models on embedded hardware extremely difficult due to slower hardware and small memory. By quantizing, we get smaller models and faster inference. However, just quantizing will lead to accuracy loss. To solve this, we need to do QAT (Quantization Aware Training) which leads to minimal accuracy loss (often <1%).

Features

• Integer weights and activations for low memory usage, small model and fast inference
• Adam optimization with batching
• Quantization-Aware Training to minimize accuracy loss
• Extremely configurable with custom network architecture, multiple activation, output, cost and learning decay functions and scaling factors
• No dynamic memory allocation
• No dependencies

On the MNIST 784 (digit recognition), we can achieve ~95% test accuracy with just 327 KB model size (vs ~1.2 MB for float32) and <1 ms inference time on a modern CPU, which is a ~14x speedup.

GitHub repo: qmtik