DEV Community: Nwobodo Ecclesiastes Chidera

I Built a Serverless, End-to-End Encrypted Messaging App That Works Without the Internet

Nwobodo Ecclesiastes Chidera — Mon, 02 Nov 2026 17:02:04 +0000

What if you could send private messages without WhatsApp, Telegram, internet access, user accounts, or centralized messaging servers?

Meet Eccles Bluechat E2EE — an experimental Android messaging application built around decentralized, Bluetooth-based communication.

Designed with privacy and independence at its core, Eccles Bluechat explores:

🔐 End-to-end encryption using ECDH, HKDF-SHA256, and AES-256-GCM.
🔑 Android Keystore-backed cryptographic key protection.
📡 Serverless, internet-independent Bluetooth messaging.
🛡️ Trust-on-first-use (TOFU) identity verification.
📁 Encrypted local message and media storage.
📞 Bluetooth-based voice and video communication.

No accounts. No advertisements. No tracking. No centralized messaging infrastructure.

This project explores an important engineering question: Can we build meaningful private communication systems without depending on the internet or centralized infrastructure?

This is an open-source engineering experiment, and I'm sharing the architecture, implementation, challenges, and lessons learned.

GitHub: https://github.com/Igwe-Starking/eccles-bluechat-e2ee

Built by Eccles (Igwe Starking).

I Gave My Phone a Brain: An Android Agent That Posts, Calls and Takes Photos From One Sentence

Nwobodo Ecclesiastes Chidera — Sun, 18 Oct 2026 14:05:41 +0000

Open-source Android AI agent: say a goal, it taps, types, swipes and opens apps for you. Gemini, OpenAI, Claude. Banking apps off-limits.
tags: android, ai, opensource, showdev

cover_image: https://raw.githubusercontent.com/igwe-starking/eccles-agent/main/docs/media/social-preview.png

I typed one sentence:

"Open Facebook and post I love programming on red background."

My phone opened the app, picked the red background, typed the text, and then stopped to ask my permission before posting.

No script. No per-app integration. Just a sentence.

Meet Eccles Agent: an open-source Android app that operates your phone for you.

⚡ What it can do

If a human can do it on screen, Eccles can try. In my own testing it has:

🔦 Flipped system toggles. "Turn on the flashlight" opens Quick Settings, finds the switch and taps it.
📘 Posted to Facebook, including picking a coloured background and typing the text.
📞 Placed a call by finding a contact, opening it and pressing call.
📸 Taken a photo. "Take a picture of my laptop, it's facing the rear camera" opened the camera and pressed the shutter.
🚀 Opened apps reliably, even when Android refuses to launch them from the background.

🧰 The toolbox

The model answers with small JSON actions, and Eccles carries them out:

open_app · click · tap · long_press · swipe · type · key · scroll · wait

{
  "thought": "Facebook is open; the composer is item 7",
  "status": "continue",
  "need_vision": false,
  "actions": [
    {"type": "click", "target": {"index": 7, "text": "What's on your mind?"}},
    {"type": "type", "text": "hello everyone"}
  ]
}

🧠 Bring your own brain

Pick the AI you already use and paste your own API key:

Google Gemini (the default)
OpenAI
Anthropic Claude
Anything OpenAI-compatible: OpenRouter, Groq, DeepSeek, or a local Ollama or LM Studio server

Switch in Settings, then tap Test connection.

🎯 It checks its own work

Android will happily report a tap as "performed" when nothing happened. Eccles counts a node action only if the UI actually reacted. If it didn't, it re-plans from a fresh screenshot instead of blindly retrying and double-tapping a "Like". Screenshots go to the AI only when the screen tree isn't enough, and you choose whether that means never, only when needed, or every step.

🛡️ An agent that can tap anything needs a hard "no"

Safety is the architecture, not a toggle:

Banking and payment apps are off-limits. They're never read, screenshotted or sent to the AI, and the guard fails closed.
Password screens stop the task.
Send, post, delete and buy need your Allow. No answer in 60 seconds counts as Deny.
A floating Stop button sits on top of every app.
Your API key is encrypted with an AndroidKeystore key, never stored in plain preferences.

📲 Install it (no computer needed)

Eccles is an Accessibility Service, so on Android 13+ an APK installed from a browser gets its toggle greyed out ("Restricted setting"). The fix takes a minute:

Install the APK and open it.
Try to enable the service, then tap OK on the warning.
Settings → Apps → Eccles Agent → ⋮ → Allow restricted settings.
Switch the service on.

Or use adb install -r EcclesAgent-1.0.apk from a computer. The README has both routes and a SHA-256 to verify your download.

⚠️ Honest limits

It's an AI driving a UI, so it can get things wrong. Watch the timeline and keep Stop in reach. Whatever is on screen during a task goes to the AI provider you choose. Some apps hide from accessibility. It isn't on Google Play yet.

🚀 Try it, break it, improve it

⭐ https://github.com/igwe-starking/eccles-agent

I built this solo on a low-end Chromebook with no budget. If Eccles Agent makes you grin, you can support the project here: https://paystack.shop/pay/support-eccles-agent-tie1

The question I'd love your answer to: what should an agent like this never be allowed to do?

I Built a Memory Allocator for Microcontrollers That Refuses to Fragment

Nwobodo Ecclesiastes Chidera — Thu, 24 Sep 2026 19:13:55 +0000

Dynamic memory on a microcontroller doesn't have to mean unpredictable memory.

On a desktop, writing:

void *ptr = malloc(size);

and later:

free(ptr);

is almost invisible to most developers.

On a microcontroller with a few kilobytes of RAM, things can get more interesting.

Your firmware can have plenty of total free memory and still fail an allocation because the available memory has become fragmented into pieces that aren't suitable for the next request.

That's the problem I wanted to attack.

So I built EcclesRTMem — a small, plain-C fixed-pool memory allocator designed for embedded systems where predictable memory behavior matters.

GitHub: https://github.com/Igwe-Starking/eccles-rtmem

The problem with the traditional heap

Imagine a 4 KB memory region.

Over time, your application performs operations like:

allocate 64
allocate 128
allocate 32
free 128
allocate 96
free 64
allocate 256
...

Eventually, the heap can look like:

┌──────┬────────┬────┬──────────┬──────┬───────┐
│ USED │ FREE │USED│ FREE │ USED │ FREE │
└──────┴────────┴────┴──────────┴──────┴───────┘

There may be plenty of free memory in total.

But if the next allocation requires one contiguous region and no sufficiently large region exists, the allocation fails.

That's external fragmentation.

On a desktop with gigabytes of RAM, this may be acceptable.

On a tiny MCU, where a few hundred bytes can matter, I wanted another option.

The idea behind EcclesRTMem

Instead of treating RAM as one giant variable-sized heap, EcclesRTMem divides it into fixed-size block pools.

Conceptually:

┌───────────────────────────────────────────┐
│ RAM │
├────────────┬──────────────┬───────────────┤
│ SMALL │ MEDIUM │ LARGE │
│ blocks │ blocks │ blocks │
├────────────┼──────────────┼───────────────┤
│ [ ][ ][ ] │ [ ][ ]│ [ ][ ]│
│ [ ][ ][ ] │ [ ][ ]│ [ ][ ]│
└────────────┴──────────────┴───────────────┘

An allocation request is assigned to an appropriate pool.

For example, a request for 20 bytes might consume a 32-byte block rather than creating a unique 20-byte hole in a general-purpose heap.

Yes, that creates internal fragmentation.

That's intentional.

The trade-off is:

«Waste some space inside blocks in exchange for keeping the overall allocation structure bounded and predictable.»

It isn't trying to replace every "malloc()"

This is important.

EcclesRTMem isn't intended to compete with sophisticated desktop allocators.

If you're running Linux with gigabytes of RAM, there are many reasons to use the standard allocator or another general-purpose allocator.

EcclesRTMem targets a different environment:

AVR
ESP32
STM32
RP2040/RP2350
nRF52/Zephyr
MSP430
Arduino
bare-metal firmware
RTOS applications
other resource-constrained systems

The project provides platform-specific locking mechanisms so the same allocator can be used across different embedded environments.

Fixed pools, but what about large allocations?

A fixed-size allocator has an obvious problem:

What happens when the requested object is larger than one block?

EcclesRTMem supports contiguous multi-block allocations.

Conceptually:

Large pool

┌────────┬────────┬────────┬────────┬────────┐
│ FREE │ USED │ USED │ USED │ FREE │
└────────┴────────┴────────┴────────┴────────┘
└───────────────┘
one allocation

The allocator still operates on fixed-size blocks, but several adjacent blocks can form one larger allocation.

This keeps the underlying memory model relatively simple while allowing larger objects.

I wanted "free()" to tell me when I screwed up

Memory bugs are painful enough without the allocator silently accepting bad pointers.

EcclesRTMem includes diagnostics for invalid frees, including situations such as:

double free
pointer outside the managed region
invalid alignment
pointers into the middle of an allocation

So instead of simply thinking:

"Something somewhere corrupted memory."

you can get a much more useful indication of what happened.

That matters enormously when debugging embedded firmware.

Because when your device is sitting in a workshop refusing to boot, "probably heap corruption" isn't particularly helpful.

The configuration is explicit

Embedded memory should be treated as a resource, not magic.

EcclesRTMem lets you configure things such as:

define ECCLES_RT_MEM_SIZE 4096ul

define ECCLES_RT_BLOCK_A_SIZE 32ul

define ECCLES_RT_BLOCK_B_SIZE 128ul

define ECCLES_RT_BLOCK_C_SIZE 512ul

The goal is to know ahead of time:

how much RAM the allocator consumes
how many blocks exist
what sizes those blocks are
what happens when the pools are exhausted

The allocator has hard configuration boundaries rather than pretending to provide unlimited memory.

Then I attacked it with randomized testing

This is probably the part I'm most interested in.

Memory allocators are incredibly easy to make look correct.

A few tests like:

allocate
free
allocate
free

prove almost nothing.

So the test suite performs randomized allocation/free workloads.

The repository includes stress tests performing 200,000 randomized operations, with canary patterns written into live allocations and checked throughout the test.

The test matrix also runs under:

AddressSanitizer
UndefinedBehaviorSanitizer
different pool configurations
different memory sizes
locking/no-lock configurations
boundary-oriented configurations

And this testing actually found a bug.

A randomized test exposed an out-of-bounds problem around the 255-block boundary.

That bug was fixed.

That's exactly what I want from an allocator test suite.

Not simply:

«"All tests passed."»

But:

«"The tests were aggressive enough to find something that was wrong."»

Concurrency matters on embedded systems

A memory allocator shared by multiple tasks can't simply assume that every environment works the same way.

An RTOS mutex isn't equivalent to disabling interrupts.

And a mutex that works perfectly from a task isn't automatically safe to use from an ISR.

That's why EcclesRTMem has platform-specific locking backends.

The project supports configurations ranging from RTOS environments to bare-metal/superloop applications where locking can be disabled.

One important limitation remains:

RTOS mutex-based backends should not be used from ISRs unless the particular platform/backend explicitly supports that usage.

That's not something I want an allocator to hide from the developer.

The trade-offs

EcclesRTMem isn't magic.

It has costs.

Internal fragmentation

A 33-byte allocation may consume a 64-byte block.

Pool boundaries

Free space in one pool doesn't automatically become usable space in another.

Bounded registry

The current design has a 255-block registry boundary.

Timing still needs hardware measurement

The design aims for predictable behavior, but formal worst-case timing measurements across real hardware are still future work.

These limitations are important because a serious embedded library should tell you where it stops being the right tool.

Why build another allocator?

Because embedded systems have different priorities.

Sometimes you don't need the most memory-efficient allocator possible.

You need one where you can answer questions like:

How much RAM can this subsystem consume?

What happens when it runs out?

Can a freed block be reused without changing the memory topology?

What happens if somebody double-frees a pointer?

What happens after 200,000 allocations?

What happens under concurrent access?

Can I configure the memory budget at compile time?

Those questions are more important to me than simply asking:

«"Does malloc work?"»

Where EcclesRTMem fits

I don't see it as a universal replacement for dynamic memory.

Think of the options as different tools:

Static allocation
│
│ maximum predictability
│
▼
Fixed pools / EcclesRTMem
│
│ bounded dynamic allocation
│
▼
Custom/general-purpose heaps
│
│ maximum flexibility
│
▼
Standard malloc/free

If you know every object's lifetime and size at compile time, static allocation is often excellent.

If you need dynamic lifetimes but want bounded memory behavior, a fixed-pool allocator becomes interesting.

If you need maximum flexibility and can accept more complex heap behavior, a general-purpose allocator may be appropriate.

The point isn't that one strategy wins everywhere.

The point is having the right tool for the system.

What's next?

There are still several things I want to improve.

Among them:

fragmentation/statistics reporting
allocation-failure counters
optional wider block registries
additional oversized-allocation strategies
more hardware-verified locking backends
measured worst-case timing on actual AVR, Cortex-M and ESP32 hardware

The next stage isn't just adding features.

It's measuring the behavior on real hardware.

Final thought

One thing embedded development keeps teaching me is that memory is hardware.

Every byte is physical.

Every synchronization mechanism has timing implications.

Every allocation strategy has failure modes.

And eventually, every abstraction has to answer to the silicon underneath it.

That's why I built EcclesRTMem.

Not to create the world's most sophisticated allocator.

Not to declare "malloc()" obsolete.

But to provide another option for firmware that needs dynamic memory while keeping its memory behavior bounded and understandable.

If you're working with an MCU where RAM is measured in kilobytes rather than gigabytes, you might find it useful.

Check it out

GitHub: https://github.com/Igwe-Starking/eccles-rtmem

If you use it, break it, benchmark it, or find a better way to solve the same problem, I'd genuinely like to know.

The heap doesn't have to be mysterious.

Hi guys am designing a JVM that will run on Esp32,soon you will be able to execute java on esp32

Nwobodo Ecclesiastes Chidera — Fri, 10 Jul 2026 15:54:47 +0000

I Built an Open-Source ESP32 Smart Bike — Ready to Flash, Test, and Improve

Nwobodo Ecclesiastes Chidera — Fri, 10 Jul 2026 10:11:12 +0000

🚴 Weekend Challenge: Build, Flash & Improve My Open-Source ESP32 Smart Bike

Looking for a serious ESP32 project to explore this weekend?

I've been building an ESP32 Smart Bike platform that combines embedded systems, Android development, networking, audio streaming, and power management into a single open-source project.

🔥 What it includes

🚴 Complete ESP32 firmware (PlatformIO)
📱 Complete Android application
📂 Ready-to-flash Firmware, Bootloader, and LittleFS images
💾 LittleFS filesystem support
⚡ Intelligent Power Manager for efficient operation
🌐 WebSocket-based CommandAction system for fast, reliable command communication
🔊 Bluetooth A2DP audio support
🎤 Real-time dual voice streaming over UDP for low-latency communication
📡 ESP32 ↔ Android integration
🧩 Modular C++ architecture that's easy to extend
📖 Fully open-source source code

This project combines several technologies that are rarely seen together in a single ESP32 application:

Embedded C++
Android development
WebSockets
UDP networking
Bluetooth A2DP
Audio streaming
Power management
LittleFS
Real-time communication

🎯 Weekend Challenge

Clone the repository, flash the ESP32, install the Android app, and put it through its paces.

I'm especially looking for feedback on:

Performance
Architecture
Code quality
Feature ideas
Bug reports
Documentation improvements

If you're interested in ESP32, embedded systems, networking, Bluetooth, IoT, or Android development, I'd love to hear what you think.

⭐ If you find the project useful, consider starring the repository. Contributions, pull requests, and suggestions are all welcome.

GitHub Repository

https://github.com/Igwe-Starking/eccles-esp32-smart-bike

Let's see what the community can build on top of it this weekend. 🚀

🔥 I Built an ESP32 Smart Bike Control System with an Android App (Open Source)

Nwobodo Ecclesiastes Chidera — Tue, 07 Jul 2026 22:23:19 +0000

🚀 I Built an ESP32 Smart Bike Control System with an Android App (Open Source)
What if your motorcycle could become a smart vehicle without replacing its original electronics?
For the past several months, I've been building Eccles Smart Bike, an open-source project that transforms a regular motorcycle into a Bluetooth-enabled smart bike using an ESP32 and a custom Android app.
Instead of replacing the bike's OEM electronics, the system integrates with the existing controls, making it smarter while preserving the original functionality.
🔥 Features
✅ Bluetooth communication between the bike and Android app
✅ Android app built in Java
✅ ESP32 firmware written in C++ using ESP-IDF
✅ Controls for indicators, horn, headlight, starter, and more
✅ Thread-safe architecture using FreeRTOS
✅ Designed to integrate with OEM motorcycle wiring
✅ Open-source and continuously improving
🛠 Technologies Used
ESP32
ESP-IDF
C++
Java
Android Studio
Bluetooth Classic
FreeRTOS
💡 Challenges
This project involved much more than simply connecting an ESP32 to a motorcycle. It required solving problems involving:
Reliable Bluetooth communication
Real-time task synchronization
Embedded software architecture
Android-to-ESP32 messaging
Integration with OEM motorcycle wiring without disrupting factory systems
Extensive debugging and testing
Every challenge taught me something new about embedded systems and automotive electronics.
🌍 Open Source
I'd really appreciate feedback from the embedded systems and IoT community. Whether it's code improvements, architecture suggestions, or feature ideas, I'd love to hear them.
⭐ GitHub Repository:
https://github.com/Igwe-Starking/eccles-esp32-smart-bike
If you find the project interesting, please consider giving it a ⭐ on GitHub—it helps others discover the project and motivates continued development.
Thanks for reading, and happy building! 🚀⚡🏍️

ESP32 #EmbeddedSystems #Android #OpenSource #IoT