Forem: Ekong Ikpe

Gnoke-Database: Firebase in your pocket.

Ekong Ikpe — Sat, 09 May 2026 16:49:12 +0000

The server doesn't need to be a warehouse. Sometimes it just needs to be a switchboard..

I built the exit door.

What Gnoke-Database is:

It is a complete backend engine — collections, auth, offline sync, roles, identity isolation, OTP recovery — that runs on any PHP host with SQLite.

Not a cloud service. Not a monthly subscription. A folder you upload once.

The cheapest shared host you can find. The one that costs less than your data bill. That host is now your Firebase.👍

What it actually does:

Your app saves records locally first. Always. No network required. When the connection returns, Gnoke pushes the queue silently. When a teammate makes a change on their device, Gnoke pulls it down. Your UI reacts. Nobody waited. Nobody lost data.

This is not a workaround. This is how it should have worked from the beginning.

Collections are scoped automatically — per user, per branch, per company — without you writing a single access rule by hand. The identity chain handles it. Same user, different app: separate data. Same app, different branch: separate data. No accidental bleed. Ever.

Roles are defined once in a config file and enforced on every request. Operators save and sync. Managers delete. Admins touch everything. You write the rule once. Gnoke enforces it everywhere.

Staff changes device. Forgets PIN. OTP recovery re-establishes the chain in under a minute. No data lost. No admin panic. 👌

The number that matters:

Firebase charges by reads, writes, and storage — and the meter runs whether you're watching or not.

Gnoke-Database runs on SQLite. One file on your server. The bill is your hosting fee. Fixed. Predictable. Yours.

One deployment serves your entire company. Multi-tenant mode gives every client their own isolated database file — same server, zero bleed, independent backups.

What this is not:. 😎

This is not a Firebase killer for Google-scale infrastructure. If you are serving 50 million concurrent users across five continents, you have different problems.

Most apps are over-engineered by default — hosted on infrastructure designed for companies a hundred times their size, paying for headroom they will never use.

Gnoke-Database is the right size. Deployable in an afternoon. Owned completely.

The philosophy in one line:

Your backend should live on your terms — not on a pricing page you didn't write.

Gnoke-Database — MIT License. Your own Firebase, on your own server.

https://github.com/edmundsparrow/gnoke-database

Gnoke Persist: Your Browser Has Short-Term Memory Loss. I Fixed It. 👌

Ekong Ikpe — Thu, 07 May 2026 02:15:29 +0000

Have you ever spent an hour typing something into a website, only for your phone to get a notification, refresh the page, and POOF—everything you typed is gone?

That happens because browsers are like Etch-A-Sketches. The moment you "shake" them (refresh or switch apps), they wipe the screen clean. This is especially true on Android, where the system often kills "sleeping" browser tabs to save battery, destroying your unsaved work without warning.

I built gnoke-persist to give your browser a permanent memory. It’s a tiny, zero-dependency script that turns your browser into a durable tool.

Here is how it works (using three tiny "robots"):

1. The Spirit (The Ghost in the Machine) 👻

The Spirit is a tiny robot that watches you type. Every time you press a key, it scribbles what you wrote into a secret notebook inside the browser.

The Magic: If the tab dies or you refresh, the Spirit reads its notebook and refills the boxes. This form recovery works across all modern browsers—Safari, Chrome, Firefox, and Edge.
The Privacy Filter: The Spirit is helpful, but it tries to be safe. It looks for words like password, token, or secret and ignores those fields. While it’s not a cryptographic vault, it’s designed to keep your secrets out of the recovery log.

2. The Shelf (The Safety Net) 🧺

Usually, if a website tries to save a file to your computer and the battery dies mid-save, that data just disappears.

The Shelf uses a "Write-Ahead" strategy. Before it even tries to touch your hard drive, it puts a copy of the data on a waiting shelf (IndexedDB). If the browser crashes, the data stays on the shelf. The next time you open the app, the robot sees the item and attempts to finish the delivery for you.

3. The Bridge (The Key-Holder) 🔑

Browsers are very protective. Even if you give a website permission to a folder, the browser "locks the door" every time you refresh the page.

The Bridge remembers where your files live. Even when the door locks, the Bridge stays standing. You don't have to pick your folder all over again; you just tap one button to provide a "user gesture." The Bridge then re-opens the path and flushes any saved work from the Shelf straight onto your computer.

The Breakdown of Capabilities

Feature	Chrome / Edge / Brave	Safari (iOS/Mac)	Firefox
Spirit (Form Recovery)	✅ Universal	✅ Universal	✅ Universal
The Shelf (Durable Log)	✅ Local Sync	✅ Local Sync	✅ Local Sync
The Bridge (Disk Write)	✅ Direct to Folder	❌ Capability Limited	❌ Capability Limited

The Technical Truth (For the Engineers)

If you prefer documentation over metaphors, here is the recovery chain under the hood:

The Spirit = State Persistence: Uses a debounced listener on input events to sync form values to IndexedDB. It attempts a final sync on visibilitychange, though durability ultimately depends on IndexedDB commit timing before a process kill.
The Shelf = Write-Ahead Logging (WAL): Every write() call is first committed to an IndexedDB object store before being sent to the File System Access API. This provides a durability layer that survives process termination.
The Bridge = Handle Re-acquisition: Manages the FileSystemDirectoryHandle stored in IndexedDB. It handles the NotAllowedError by providing an orchestration layer that re-requests permission via a user gesture, then flushes the WAL (the Shelf) to disk.

Why should you care?

Most web apps are "flimsy." I wanted to build something "Durable." * Zero Dependencies: A tiny vanilla script. No heavy engines, no cloud required.

Private & Local: Your data stays in your browser and on your disk.
Progressive Grace: It recovers what it can everywhere, and does the heavy lifting where the browser allows it.

The vibe is simple: Stop losing work.

Check it out:

Code: github.com/edmundsparrow/gnoke-persist
The Demo: Click here

gnoke-persist v0.1.1 · Edmund Sparrow · MIT 2026

Gnoke Council — Manual Mode

Ekong Ikpe — Tue, 05 May 2026 05:31:00 +0000

One thread. Multiple AIs. Deliberation, not polling.

Most people use AI like this: 🤦

Ask one model → get one answer
Ask multiple models → compare results

That’s not thinking. That’s polling.

What if the AIs could see each other? 🤔

Not side by side.

Not isolated.

But in sequence — where each one reads what the previous one said before responding.

What This Is

Manual Council is the simplest form of that idea.

No backend.

No orchestration.

No system doing anything for you.

Just you — passing context forward.

How It Works

You act as the router.

Send your prompt to the first AI
Take its response
Paste it into the next AI
Repeat

Each model inherits the context of the previous one.

Flow

You → Claude → Gemini → GPT → Grok → You

Not parallel.

Not voting.

Sequential awareness.
Coordinated responses

What Changes

Later models correct earlier ones
Weak assumptions get exposed
Ideas evolve instead of resetting
Disagreement becomes visible

The output starts feeling worked through.

Why This Matters 🧘

Polling gives variation.

Deliberation gives progression.

Manual Council:

preserves context
compounds reasoning
enables interaction between models

The Tradeoff

Yes — it’s manual.

You copy. You paste. You decide the order.

That friction gives:

control
visibility
understanding

Try It

Design a browser-native persistence system that survives tab death without a backend.

Pass responses forward exactly as they are.

What This Could Become

Automation can come later.

This already works.

The Point ✍️

Not which AI is better.

What happens when they think together?

When one model feels off, don’t switch—run a council. 👌

*Live Demo * https://edmundsparrow.github.io/gnoke-council

GitHub: https://github.com/edmundsparrow

Tabs are apps. The OS just never told the browser 🤷

Ekong Ikpe — Mon, 04 May 2026 11:12:37 +0000

You have five tabs open right now.

Binance on tab 1. Gmail on tab 2. Scrabble on tab 3. Excalidraw on tab 4. Tab 5 — Gnoke Council — four AIs deliberating together, you as the human moderator, Claude and Gemini and GPT-4o and Grok each building on what the others said. One HTML file. No backend. No API key. Just a tab.

You're switching between them like apps. Because that's exactly what they are — apps. Web apps. Running in a browser that was designed to forget them the moment the OS decides to free some RAM.

And when that happens? Gone. Half-typed message. Lost diagram. Wrecked game state. A deliberation mid-thought.

That's not a browser limitation. That's a missing abstraction. 🧩

The thought that started this 🤔

If a browser can recover a file after a crash, why can't it recover the whole session?

Not autocomplete. Not localStorage you wire up yourself every single time. The whole thing — form state, scroll position, focused field — restored silently, before first paint, as if nothing happened.

That's what gnoke-spirit does.

What it isn't 🙄

This isn't localStorage. That's dumb key-value. You put a string in, you get a string back. You manage everything manually — what to save, when to save, when to clear. Every app reinvents the same plumbing from scratch.

This isn't browser session restore either. That's passive, unpredictable, scoped to the browser's mood. Clears on hard reload. You can't name it, query it, or kill it deliberately.

What it actually is 😎

A process model for the browser.

gnokeSpirit.wake();

One line. The tab is now a process. It has an identity — pid defaults to location.pathname, so each route is its own isolated process. It has memory (IndexedDB). It knows what to persist and what to never touch.

Kill the tab. Reopen it. It picks up exactly where it left off.

await gnokeSpirit.wake('/editor');    // Tab 1 — its own process
await gnokeSpirit.wake('/settings');  // Tab 2 — isolated, independent
// Kill either. Both come back. Neither knows the other crashed.

What gets persisted. What never does.

Persisted	Never
Text inputs	Passwords
Textareas	Tokens / secrets
Select values	Auth state
Scroll position	Anything sensitive
Active field focus

The sensitive filter isn't optional. It's baked in. You can't accidentally persist a password field. Security by default, not by configuration.

The engineering decisions that matter

One DB connection, cached for the page lifetime.
No repeated indexedDB.open() calls. One connection, reused. This matters on mobile — battery and latency both.

Schema versioning from day one.
Empty migration hook now. But when the state shape changes in v2, existing users don't lose their processes. Most people skip this and regret it.

Awaited writes everywhere.
The visibility handler — the last write before the OS kills the tab — is awaited. That's the survival write. It has to land.

Zero dependencies. No build step. 2kb.
Drop a script tag. Call wake(). Done.

The API

await gnokeSpirit.wake(pid?, formEl?)
// Start the spirit. Restores last state immediately.
// pid defaults to location.pathname — each route is its own process.

await gnokeSpirit.kill(pid?)
// Wipe process memory.

await gnokeSpirit.list()
// Returns all active process IDs. Your process table.

Where this goes next 👀

Right now each tab is its own isolated process. That's already useful.

But imagine two tabs coexisting in a split UI — Excalidraw on the left, your notes on the right — each holding its own memory, neither crashing the other out when the OS gets impatient. Drag a tab into the perimeter. It brings its state with it. No reload. No memory loss.

That's the next layer. The browser as an actual OS. Tabs as actual apps.

What this actually is

localStorage stores values.

gnoke-spirit preserves where a user was.

Those are different things. One is plumbing. The other is a contract — ship it with any webapp and tabs become resumable. The developer stops thinking about storage. The user never notices. It just works. 🔥

The browser is an OS. Tabs are apps. gnoke-spirit is the missing layer between them.

What do you think — is the browser finally ready to be treated like an OS? Or are we still stuck thinking in pages?

Live demo: edmundsparrow.github.io/gnoke-spirit

Source: github.com/edmundsparrow/gnoke-spirit — MIT

Thanks to @sylwialaskowska whose engagement on the first post gave this legs.

I Accidentally Wrote a Filesystem Driver. For a Browser. 🤔

Ekong Ikpe — Sun, 03 May 2026 07:04:22 +0000

Staring at a bug report that makes no sense.

Data gone. No error. No warning. No stack trace. Just… gone.

Your app writing files using the File System Access API — which, by the way, is genuinely one of the most exciting things that's happened to the browser in years. A user picks a folder. You write to it. Clean, native, no server involved. The dream, right?

Except on mobile, the dream has a bad habit of dying quietly.

Here's what was actually happening

The browser process got killed in the background. Completely normal — Android does this all the time when memory gets tight. Writable stream was mid-write when it happened.

No error was thrown. The write just… didn't complete.

And then you start digging. And you realize — this isn't a bug you can patch. It was a category of problem.

The OS kills your process → your in-flight write disappears
You reopen the app → your file handle is stale
You fire ten writes at once → the File System Access API doesn't serialize them, so they race, collide, and most of them silently fail

Three completely different failure modes. All silent. All data loss.

I fixed them. I wrote a write-ahead buffer, a per-filename queue, an IndexedDB fallback shelf, and a recovery mechanism that replays shelved writes on next wake.

And then I looked at what I'd built and thought…

wait.

This isn't a web feature. This is a kernel problem.

Write ordering. Process lifecycle. I/O durability. Recovery after crash.

These aren't things you solve in web apps. These are things you solve in operating systems.

Which made me ask a question I couldn't stop thinking about: why did I hit OS-level problems inside a browser?

The uncomfortable answer: because the browser is already an OS.

Not metaphorically. Not "kind of." Actually.

It has a process manager (tab lifecycle, background kill policies).
It has a filesystem (File System Access API, Origin Private File System).
It has persistent storage (IndexedDB, Cache API).
It has a network stack (fetch, WebSockets, WebRTC).
It has a GPU interface (WebGPU).
It has a concurrency model (Web Workers, SharedArrayBuffer).
It can even run compiled binaries (WebAssembly).

That's not a list of "web features." That's a kernel feature set. 😳

And yet… we're still building like it's 2010

Most frameworks still treat the browser like a dumb UI layer sitting on top of a real backend. State lives on a server. Files live on a server. Compute lives on a server. The browser is just the face.

But the platform has quietly moved on.

The browser isn't asking your server for permission anymore. It's got its own filesystem. Its own persistent storage. Its own compute pipeline. Its own process isolation.

We just haven't caught up to what it actually is.

What developers are building instead

Here's the thing that gets me. 🤔

Look at Electron. Look at Tauri. Look at Capacitor. Look at every "make a web app feel native" framework that's shipped in the last decade.

What are they all doing? They're wrapping the browser. Giving it a launcher. Giving it a system tray icon. Giving it access to APIs it wasn't "supposed" to have.

They're building a skin. A controlled launcher for a runtime that already had the OS capabilities — it just hadn't admitted it yet.

The browser doesn't need a wrapper to be an OS. It is one. The wrappers exist because we haven't fully accepted that yet.

The moment it clicked for me

When I finished gnoke-savenative — my little durability layer for mobile browser writes — I described the architecture to a friend.

Write-ahead buffer. Fallback shelf. Replay on wake. That's WAL. Write-Ahead Logging. The same durability primitive PostgreSQL uses to survive crashes. Implemented inside a browser tab.

That's not a web developer problem. That's a systems programming problem.

And I solved it inside a browser tab.

So what does this mean practically?

I think we're in a weird transitional moment. The browser runtime is already powerful enough to be treated as a first-class OS — but most developers are still building on top of it like it's a view layer.

The ones who figure this out first get to build the system services. The filesystem drivers. The process managers. The things that sit below the app layer and make everything else reliable.

That's where I'm going with the Gnoke Suite. Not apps that run in a browser. A system layer that runs as the browser.

It's a subtle difference. But I think it changes everything about how you architect what you build. 🧠

If you want to see what a browser filesystem driver actually looks like in practice:

👉 gnoke-savenative on GitHub

Live Demos

🏎️ The Native I/O Driver

Note: Demonstrates raw disk access; permissions reset on refresh by design.

🧠 The Session Persistence Layer

Note: How I solve the 'refresh' problem using IndexedDB memory.

And if you've hit similar problems — silent write failures, stale handles, mobile process kills — I'd genuinely love to hear about it in the comments. I have a feeling more people have run into this than have written about it.

— Edmund Sparrow, Gnoke Suite

Gnoke SaveNative: A Durability Layer for the File System Access API on Mobile Browsers

Ekong Ikpe — Sun, 03 May 2026 05:53:01 +0000

I was building offline-first apps for the Gnoke Suite and ran into the same wall every time.

The File System Access API works beautifully — until your phone decides otherwise.

A background OS kill. A tab reload at the wrong moment. Ten concurrent writes racing for the same stream. Any of these silently drops your data. No error. No warning. Just gone.

The browser fantasy is: pick a folder, write files, done.

The mobile reality is: your process dies, your handle goes stale, and your writable stream errors out mid-write. 😬

So I built a survival layer around it.

Meet gnoke-savenative

A two-layer write pipeline for browser apps. Native filesystem first, IndexedDB shelf as instant fallback.

npm install gnoke-savenative

import { saveNative } from 'gnoke-savenative';
import { openDB }     from 'idb';

// Mount once (user gesture required)
const handle = await saveNative.mount(openDB);
let workspace = { handle, db: await saveNative._db(openDB) };

// Write — native first, shelf if it fails
await saveNative.write(workspace, 'notes.txt', 'Hello world');

// After reload — wake restores handle and auto-flushes shelf
workspace = await saveNative.wake(openDB);

The Survival Loop

Every write has a guaranteed outcome — it's either on disk or in the shelf.

write()
  ↓ native success → file on disk ✓
  ↓ native failure → shelved in IndexedDB

wake() after reload
  ↓ handle restored
  ↓ _flush() drains shelf → file on disk ✓

Writes are never dropped — only delayed. Recovery is automatic. Visibility is optional via hooks.

What makes it mobile-ready 📱

On desktop, the File System Access API mostly just works. On mobile (tested on Infinix Android, Chrome), three things will break a naive implementation:

1. OS background kills

The browser process dies. The handle survives in IndexedDB. But the write that was in-flight is gone. The shelf catches it.

2. Stale writable streams

Open a stream, come back after the OS has changed something on disk — the stream errors. Every write goes through a fresh createWritable() call.

3. Concurrent write races — this is where most implementations silently fail 🤷

The File System Access API does not serialize concurrent writes to the same file. Fire ten writes at once and they fight over the same stream — most fail with no error. gnoke-savenative maintains a per-filename queue so writes process in strict order. This is not retry logic — it's guaranteed ordering backed by a persistent fallback. v0.1.1 was specifically a concurrency patch after stress testing exposed false shelf activations on clean writes.

The API

saveNative.mount(openDB)                    // pick folder, stash handle
saveNative.wake(openDB)                     // restore handle, auto-flush shelf
saveNative.write(workspace, name, content)  // queued write with shelf fallback

Optional hooks for UI feedback:

saveNative.onWriteFailure  = (name, err)   => { /* shelved */ };
saveNative.onFlushProgress = (done, total) => { /* draining */ };
saveNative.onFlushComplete = (count)       => { /* recovered */ };

How it was built

This came out of a real stress test — a Ghost Editor testbench on a real Infinix device, with hard reloads, app switches, and 10 concurrent writes fired at once.

The pattern is essentially a write-ahead buffer with eventual durability: attempt the native write, fall back to the shelf on failure, replay on wake. The same principle behind WAL in database engines — applied to the browser filesystem. 🧠

v0.1 proved the shelf worked.

v0.1.1 eliminated false shelf activations under concurrent writes.

After the stress test showed zero shelf activations on clean concurrent writes, it was ready to ship. ✅

Try it

👉 github.com/edmundsparrow/gnoke-savenative

Zero dependencies (brings your own openDB). MIT licensed. Vanilla JS ES module.

Drop it in any project via CDN — no npm, no build step:

<!-- ES module -->
<script type="module">
  import { saveNative } from 'https://cdn.jsdelivr.net/gh/edmundsparrow/gnoke-savenative/gnoke-savenative.js';
  import { openDB }     from 'https://unpkg.com/idb?module';
</script>

<!-- Or plain script tag — window.saveNative available globally -->
<script src="https://cdn.jsdelivr.net/gh/edmundsparrow/gnoke-savenative/gnoke-savenative.js"></script>

— Edmund Sparrow, Gnoke Suite

Gnoke flatJSON — My JSON detection logic is now a library you can use.

Ekong Ikpe — Tue, 21 Apr 2026 12:34:04 +0000

Gnoke-flatjson

⚠️ Users would import a JSON file and the table would either crash, show [object Object] in cells, or worse — silently drop entire columns without warning.

The problem wasn't the table renderer. It was that JSON has no single shape.

An API response looks like this:

[{ "name": "Alice", "age": 30 }]

A database export looks like this:

{ "people": [["name","age"], ["Alice", 30]] }

A spreadsheet export looks like this:

[["name","age"], ["Alice", 30]]

They all mean the same thing. But every shape needs different handling.

🔧 So I wrote a normalizer — a function that accepts any of these shapes and always returns the same thing:

{
  headers: ["name", "age"],
  rows: [["Alice", "30"]]
}

Over time it grew to handle 8 formats: silent column drops, [object Object] cells, broken row ordering on mixed arrays — all handled at the normalization layer, before any renderer ever sees the data.

Eventually I realised — this logic deserves its own home.

So I extracted it.

📦 Meet gnoke-flatjson

One function. Any JSON in. Clean { headers, rows } out.

npm install gnoke-flatjson

const flatJson = require('gnoke-flatjson');

const result = flatJson(data);
// result.headers — column names
// result.rows    — all cells as strings

Or drop it straight into any HTML file — no npm needed:

<script src="https://cdn.jsdelivr.net/gh/edmundsparrow/gnoke-flatjson/index.js"></script>

🗂️ What it handles

Input shape	Example
Array of objects	`[{ name: "Alice" }]`
Array of arrays	`[["name"],["Alice"]]`
Entity-wrapped	`{ "people": [["name"],["Alice"]] }`
Explicit headers/rows	`{ headers:[], rows:[[]] }`
Single object	`{ name: "Alice" }`
Array of primitives	`["Alice","Bob"]`
Inconsistent keys	Missing keys become empty strings, no columns dropped
Nested objects	Stringified as JSON instead of `[object Object]`

🔗 Try it live

There's a demo page where you can paste any JSON and see the result instantly — including a rendered table.

👉 edmundsparrow.github.io/gnoke-flatjson

✂️ The utility was born from a real app solving a real problem. Gnoke DataForge was the inspiration.

Zero dependencies. MIT licensed. 68 lines.

— Edmund Sparrow, Gnoke Suite

Gnoke: Repurposing E-Waste into Zero-Energy Knowledge Devices

Ekong Ikpe — Mon, 20 Apr 2026 05:57:04 +0000

This is a submission for [Weekend ---
**Challenge: Earth Day Edition* 🌍

(https://dev.to/challenges/weekend-2026-04-16)

What I Built

Gnoke turns discarded smartphones into zero-energy knowledge devices—reducing e-waste and eliminating reliance on the cloud.

I built Gnoke Bible, an ultra-lightweight, offline-first digital reader designed to extend the life of old, low-spec devices. Instead of letting aging smartphones become landfill, Gnoke repurposes them into permanent, offline knowledge tools.

Once loaded, the app runs with:

Zero data usage 📴
Zero server dependency ☁️
Minimal battery consumption 🔋

This eliminates repeated data downloads and reduces reliance on energy-intensive cloud infrastructure.

Demo

🔗 https://edmundsparrow.github.io/gnoke-bible

Code

💻 https://github.com/edmundsparrow/gnoke-bible

How I Built It

Ultra-Low-Resource Development

The entire project was designed and built on a low-end Infinix Android device, targeting the same class of hardware it aims to preserve. This ensured real-world performance optimization for constrained environments.

Technical Decisions

Vanilla Stack: Built with HTML, CSS, and JavaScript only — no frameworks
Offline-First Architecture: Service Workers and localStorage store all content locally
Energy Efficiency: Minimal CPU usage and reduced battery drain
Device Longevity: Optimized for low RAM to keep older phones usable

Why It Matters (Earth Impact) 🌱

Reduces e-waste by extending device lifespan ♻️
Eliminates repeated data downloads, lowering energy consumption ⚡
Reduces reliance on cloud servers, lowering carbon footprint 🌍
Reduces paper demand by replacing frequently printed materials with a one-time digital download 📚
Helps preserve trees by lowering repeated printing of books and documents 🌳

Prize Categories

Best Use of Google Gemini ✨

Google Gemini was used as a lightweight collaborator to refine optimization decisions and improve system efficiency.

Defending Vibe Coding: Why Syntax Might Not Be the Bottleneck Anymore

Ekong Ikpe — Mon, 13 Apr 2026 08:52:18 +0000

So many talk about vibe coding and its negative effects or error-prone designs. I got tired of it and felt I should make one more post. 🙂

There’s been a growing debate in tech about AI-assisted coding and whether people who use it truly “understand” what they’re building.

From my experience building real offline-first apps, I think this debate is based on an outdated assumption — that you must understand every line of code to be a real builder. 🤔

Building Has Changed

I started building apps by describing what I wanted, not by writing code.
“A Gasap retailers webapp to track daily gas sales ”
“An offline reader”
“A simple system that stores and retrieves data in the browser”

AI generates the implementation. I test behavior in real usage. Over time, the focus shifted from syntax to:

system behavior
real-world usefulness
whether it solves the problem 🙂

The real skill is not writing code; it is:

Clearly describing intent and recognizing when the system does not match it.

If something breaks, I don’t need to understand every line of code to describe the symptom and get it fixed.

What Has Changed

AI has not removed engineering. It has removed manual construction.

The effort has shifted to:

defining what should exist
validating what was generated
iterating until behavior matches intent

Personal Context

My long use of Windows XP and Windows 7 eventually birthed the idea of Gnokestation — making the vibe engineering process feel less like a headache.

Imagine building and coding an entire operating system from an Android phone. That experience pushed me further into thinking that the bottleneck is no longer syntax, but execution clarity and system design.

In the same direction, I’ve replaced most of my Play Store apps with Gnoke Apps, and I’m genuinely satisfied with the experience. They are:

ad-free
lightweight
offline-first
focused on simple tasks
no forced logins or password saving

Just clean tools that do exactly what they’re meant to do. 🤷

Real-World Iteration Matters

This approach also affects how I handle more complex systems.

For example, I had started working on HMI templates, but I stepped back from pushing "Gnoke-OBD2" further because I didn’t yet have a reliable way to thoroughly test the system in real conditions.

Instead of forcing it out, I paused it until the validation environment is solid enough.

That’s part of the same principle — build fast, but only ship what you can properly verify. 🚴

Final Thought

I don’t see AI as replacing understanding. I see it as replacing typing.

If I can describe a system clearly, and AI can translate it into working software that I can verify in real use, then the value is not in writing code.

The value is in building something that works.

Wishing you a productive working week. ✌️

vibecoding #webdev #buildinpublic #automation #gnokestation #gnokeapps

Gnoke-timetravel: find out your date for reincarnation. You might come back in the past. 🥺

Ekong Ikpe — Sat, 04 Apr 2026 04:58:48 +0000

This is a submission for the DEV April Fools Challenge

What I Built

Gnoke TimeTravel ⏳

A lightweight, browser-based "Cosmic Return Date" calculator. Using a proprietary (and highly questionable) karma engine, this app determines exactly when the universe will allow you to return to Earth based on your life choices and plant-parenting skills.

🌟 Features

Karma Engine: A logic-based quiz that evaluates your cosmic standing.
Dynamic Calculation: Predicts your return year and "Era" based on your total karma score.
Gnoke Design System: A clean, cosmic-themed UI with a focus on typography and smooth transitions.
Dark Mode: System-aware and manual toggle support.
Offline First: Built as a PWA with a Service Worker for reliable performance anywhere in the galaxy.
Zero Dependencies: Pure Vanilla JS, HTML, and CSS.
☕ TEA‑RRIFIC

Demo

Live Demo

Code

GitHub Repository

How I Built It

Frontend: HTML5, CSS3 (Custom Properties/Tokens)
Logic: Vanilla JavaScript (ES6+)
State Management: Custom Pub/Sub pattern (state.js)
Persistence: localStorage for theme preferences.
Icons: Emoji-based for zero asset overhead.
Built on: Infinix Hot 12 Play (mobile-first approach)

Prize Category

Community Favorite — it's delightfully useless, fun, and deterministic. ☕ TEA‑RRIFIC.

Gnoke Reader — A Universal Offline Document Viewer for Developers Who Work With Files

Ekong Ikpe — Mon, 23 Mar 2026 19:10:26 +0000

This is part of the Gnoke Suite — offline-first tools for developers.

The Problem

You open a .log → one app

A .env file → another

A .csv → Excel (slow for no reason)

A .diff → now you're stuck

Why are we still doing this in 2026?

Developers, writers, and technical people constantly deal with raw files — logs, configs, dumps, patches — but there’s no simple, offline-first, no-setup viewer that handles all of it cleanly in one place.

So I built one.

What I Built

Gnoke Reader — a universal offline document viewer that runs 100% in the browser.

Open it. Drop a file. Read instantly.

No upload. No account. No server.

If your file opens in a browser, Gnoke Reader should be able to read it.

Supported formats out of the box:

📝 Markdown — rendered with syntax-highlighted code blocks
📕 PDF — paged canvas renderer with keyboard navigation
📘 Word Document (.docx) — clean HTML conversion
📊 CSV / TSV — sortable table with row numbers and column count
{ } JSON — collapsible tree viewer
🖥️ Log files — level-aware colour coding (ERROR, WARN, INFO, DEBUG)
⚙️ Config files (.ini, .cfg, .conf, .toml) — section + key/value colouring
🔐 .env files — sensitive values masked by default, tap to reveal
📋 Diff / Patch — added/removed line colouring with a stats bar
🗄️ SQL — keyword syntax highlighting, zero runtime dependencies

Everything runs locally.

Search, font size control, dark/light mode, and recent files are built in.

Demo

🔗 Live: https://edmundsparrow.github.io/gnoke-reader

Drop a file → it opens instantly. No loading screens, no waiting.

On Android, you can share files directly into Gnoke Reader from your file manager — same way you’d share to WhatsApp or Drive.

Code

https://github.com/edmundsparrow/gnoke-reader

A universal offline document viewer — Portable. Private. Offline-first.

How I Built It

The entire app is vanilla HTML, CSS, and JavaScript — no framework, no build step.

The core is a plugin registry in reader-core.js.

Each format is a self-contained plugin that registers:

its file extensions
an icon
an optional CDN library (only if needed)
a render() function

When a file is opened, Gnoke Reader:

Detects the extension
Lazy-loads any required library (only once)
Calls render()

That’s it. No framework gymnastics. No bundlers. Just the browser doing the work.

Interesting technical decisions

The most interesting parts were the zero-dependency formats:

SQL — custom character-by-character tokenizer handling strings, comments, and 150+ keywords across DDL, DML, functions, and types
.env — detects sensitive keys (PASSWORD, SECRET, TOKEN, API_KEY) and masks values by default with tap-to-reveal
Diff — parses unified diff format to generate a stats bar (files changed, additions, deletions) before rendering
Search — recursive DOM text-node walker; no indexing, no library, works across every format after render

Offline First, By Design

Files never leave the device.

Recent file metadata (name and date only — never content) is stored in localStorage.

The PWA share_target means Android users can send files directly into Gnoke Reader without installing anything beyond “Add to Home Screen.”

Gnoke Reader is basically a universal “open with…” for developers — but offline, private, and instant.

Replacing $5,000 of industrial equipment with a browser tab

Ekong Ikpe — Sun, 22 Mar 2026 06:30:42 +0000

Why Your Next Industrial HMI Should Just Be a Browser Tab

A standard industrial signal tower setup can cost around $15,000 once you factor in the HMI panel, the physical tower, and the proprietary software licenses that tie them together.

I rebuilt that same functionality in a browser tab.

The demo runs on your phone’s flashlight to prove the concept. The same Web Serial and WebUSB APIs that control a smartphone torch can also control real PLCs, relay boards, and industrial signal towers.

The $15,000 Problem: Vendor Lock-in

Industrial Human-Machine Interface (HMI) panels are expensive for reasons that have little to do with hardware.

When you buy one, you are not just buying a screen. You are paying for:

Proprietary OS: A black box that no one else supports
Walled garden: A vendor-specific programming environment
License fatigue: Fees per seat, per version, per upgrade
The downtime trap: A 6-8 week lead time when a screen breaks

And the screen always breaks.

When it does, production stops while you wait for a vendor who knows you have no alternative. That is the real cost - not the unit price, but the forced friction.

The Shift: The Browser as a Universal HMI

Modern browsers already ship with APIs that industrial vendors charge thousands of dollars to replicate.

Requirement	Industrial Solution	Browser Equivalent
Display	$3,000+ HMI Panel	Any device with Chrome/Edge
Serial Comms	Proprietary Driver	Web Serial API
USB Control	Custom SDK	WebUSB API
Camera/Torch	N/A	`getUserMedia` + constraints
Offline Ops	Local runtime install	Service Workers + PWA
Deployment	IT ticket + vendor	Paste a URL

SignalTower is a proof of concept built on this shift.

It is an Andon-style stack light controller (Red, Amber, Green) with four operating modes and twelve timed patterns, installable in seconds on almost any device.

Architecture: Vanilla JS, No Build Step

To keep the system resilient and "Raspberry Pi friendly", I used:

Zero frameworks
Zero dependencies
Zero build process

Stack

Core: HTML5, CSS3, Vanilla JS
Persistence: localStorage
Hardware output:
- getUserMedia (torch)
- Web Audio API (alerts)
UX: Vibration API
Reliability: Service Workers (offline PWA)

Structure

state.js   -> runtime state (single source of truth)
theme.js   -> theme + anti-FOUC
ui.js      -> toasts, modals, status UI
tower.js   -> signal logic + pattern engine
update.js  -> version check
app.js     -> bootstrap + DOM wiring

app.js is the only file that touches DOM events.

Everything else exposes a clean API. That makes the system portable, predictable, and easy to drop into embedded environments.

The Hardware Trick: Using the Torch

The demo uses the phone’s camera torch as a stand-in for real hardware.

const stream = await navigator.mediaDevices.getUserMedia({
  video: { facingMode: "environment" }
});

const track = stream.getVideoTracks()[0];

await track.applyConstraints({
  advanced: [{ torch: true }]
});

No video is recorded or displayed.

The track is simply a handle to hardware.

Swap this with a Web Serial write to a relay board, and you are controlling a 24V industrial signal tower with the same logic.

Deployment: Where This Actually Wins

Because SignalTower is a Progressive Web App (PWA), deployment is trivial.

When a device fails on the factory floor:

Replace it with any cheap tablet
Open the URL
Add to home screen

That is it.

The Service Worker loads the app offline, and localStorage restores the configuration.

Recovery time drops from weeks to minutes.

No vendor calls. No licensing. No installation.

The Safety Question

The obvious concern:

"Anyone can deploy a control UI from a URL. That is dangerous."

This mixes up interface with control authority.

In real industrial systems:

PLC logic handles safety decisions
Physical interlocks enforce hard limits
Network isolation restricts access

The UI is just a surface.

This approach does not remove safety layers. It removes expensive, proprietary interfaces sitting in front of them.

Try It

Live demo: https://edmundsparrow.github.io/gnoke-signaltower
Source code: https://github.com/edmundsparrow/gnoke-signaltower

SignalTower also runs inside GnokeStation, a browser-based environment for running multiple industrial tools on a single screen.

Final Thought

If a browser can:

Talk to serial devices
Control USB hardware
Work offline
Run on anything

Then the real question is:

Why are we still paying thousands for dedicated HMI panels?

Looking for feedback:

If you work in embedded systems, PLCs, or industrial automation:

Where would this fail in a real deployment?
Where could it replace existing systems today?

I am especially interested in edge cases and real-world constraints.