DEV Community: Nayananshu Garai

Sky-Whisper

Nayananshu Garai — Sun, 11 Oct 2026 14:49:34 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

SkyWhisper turns stargazing from a looking activity into a listening one. You open the app at home, it computes exactly what's over your sky tonight, writes you a ~90-second narrated guide, and synthesizes it into audio you download. Then you go outside, put the phone face-down, lock the screen — and just listen through your earbuds, with lock-screen controls handling the rest.

It's for everyone who has ever held a glowing phone up to the night sky and ruined the very thing they went out to see: your eyes need 20–30 minutes of darkness to fully adapt, and one glance at a bright screen resets that clock to zero. Every other stargazing app is the screen. SkyWhisper's entire thesis is that in the field, the screen's only job is to stay off — if you never unlock your phone, you used the product perfectly. That's about as "touch grass" as software gets: the output isn't content to consume, it's instructions to look up.

Demo

Live: https://sky-whisper.onrender.com (free tier — first load after idle takes ~30–60s while the container wakes)

The 60-second try-it script:

Allow location (or type coordinates) → Prepare My Sky → watch the ritual stages light up with real server progress, not a fake timer.
Press play on the countdown → flip your phone face-down → control it from the lock screen.
Tap the 🎙 button and say "describe the sky" — or "where can I find Vega?" — and hear the agent answer from live data.
Open any pack's "Tonight's Narration" card: it tells you exactly which model narrated it — or precisely why the template did instead. No black boxes.

Code

https://github.com/N-Garai/Sky-Whisper

How I Built It

The one architectural decision everything hangs on: coordinates are computed, never generated. A deterministic ephemeris stack (Skyfield + JPL data, CelesTrak + SGP4 for satellites) calculates Sun, Moon, 5 planets, 18 named stars, and 12 constellations for your exact spot and second. The language model only ever receives those finished facts — and every number it utters is checked against them before audio renders. A closed model guessing "what's above you" would be unfalsifiable and occasionally confidently wrong; open math can be diffed against Stellarium by anyone.

The model chain is built for a world where model IDs die. During this build, Groq retired one default ID and NIM returned 410 Gone on another — I watched it happen in the logs. So each rung carries a fallback ID (switched only on 404/410-class errors), each rung gets 55 seconds, the whole walk gets 150, every failure is recorded with its reason, and the deterministic template always answers. The pack JSON — and the UI badge on it — names the winning rung or explains exactly why the template did. Model rot can't silently break this product.

Mastra (@mastra/core, Apache-2.0) orchestrates narration: a docent agent with real tools (get-sky-snapshot over localhost, get-body-direction for any named body), a facts → narrate → validate workflow, per-rung endpoint pinning, and a zod narration envelope — with the Python validator re-gating everything as the final word. Voice questions ride the same chain with conversation memory, answered as speech.

Free-tier engineering: the whole serving footprint peaks around ~320MB of 512MB; the Node harness spawns only when a model rung actually runs and is kill-guarded so hung runs can't orphan processes into an OOM; packs cache on 15-minute sky buckets so retries serve instantly; the kernel and satellite data warm at boot.

The frontend: (React 19, Vite, Tailwind v4, Framer Motion, Three.js living starfield, installable PWA with offline pack cache) also ships two things I'm proud of: a drag-to-turn 360° sky map with a live facing readout, and a blackout pointer mode — pure-black OLED overlay where compass, vibration, and rising pitch guide your aim onto a star without emitting a photon that matters.

Testing: 136 automated tests, hermetic (no network, no keys) — ephemeris math, anti-hallucination rejection (including a test pinned from a real production failure where a model emitted raw altitudes), chain fallthrough, kill-on-timeout, and full HTTP integration.

Why Does Open Innovation Matter?

Four concrete ways, all demonstrated in code rather than claimed in prose:

Open coordinates are a correctness feature. My cross-check table (in docs/accuracy.md) diffs Skyfield against astropy's independent implementation: 0.00° across the board except a 0.64° lunar-elongation residual I document and explain. Try auditing a closed API's sky positions that way.
Swap-ability is a one-line demo. Hosted Gemma via free key → local Ollama via one variable. A closed-API product cannot offer "run my narrator on your laptop with zero code changes"; the open-weight one does, and location history ("where you stargaze") never has to leave your machine.
It costs nothing to run. Free Render + free model tiers + free TTS tier + free data sources = $0/month, every line auditable. Open is what makes the hobby budget possible.
It survives the real world. When providers retired model IDs mid-build, the open, inspectable stack meant I could see exactly what broke (HTTP 404/410 in plain text) and route around it in the open — instead of a black-box outage I couldn't diagnose.

Prize Categories

Best Use of Render — single free web service serving API + PWA; cold-start honesty, ephemeral-by-design storage, measured 320MB footprint on 512MB.
Best Use of Gemma — open-weight Gemma narrates from computed facts only (never coordinates), hosted free-tier path plus one-variable local Ollama swap, model recorded per pack.
Best Use of ElevenLabs — pre-trip TTS rendering with an honest transcript-only mode when unkeyed; short voice replies synthesized on demand.
Best Use of Mastra — docent agent with snapshot/direction tools, facts→narrate→validate workflow, per-rung orchestration, memory-carrying voice loop.

Bill-Bhasa

Nayananshu Garai — Sun, 04 Oct 2026 14:54:36 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

BillBhasha — a privacy-first bill scanner that reads any paper receipt, prescription, or invoice out loud in my parents' own language.

My mother is 62, hindi-first, and has low vision. She still handles every household bill, medicine strip, and ration document by hand. Right now that means either squinting at faded paper or asking someone else to read it for her — and neither option lets her stay independent.

BillBhasha lets her simply take a photo of any document. The app cleans the image, reads the text with open-source OCR, understands it with an open-weight language model, and then speaks the explanation back in warm, simple Hindi or Bengali. It also watches her spending history and speaks a gentle warning when an amount jumps unusually.

Everything runs inside a single free-tier web service. No app store, no login, no credit card. She opens the site, snaps a photo, and listens.

Demo

Live link: https://billbhasha.onrender.com (first visit may take ~40s to wake the free service)
How it feels for her: open the page → tap the camera → snap a bill → hear a 30-second Hindi explanation → see a plain ₹ amount and a simple "check this" warning if something looks off

Code

GitHub repo: https://github.com/N-Garai/Bill-Bhasa
Stack: FastAPI backend · Tesseract OCR · SmolLM2-360M (GGUF, Apache-2.0) · Piper Hindi/Bengali voice · Neon Postgres · vanilla JS frontend with GSAP + Three.js

How I Built It

BillBhasha is not a wrapper around a closed API.

Open-weight model at the core

The default brain is SmolLM2-360M in GGUF format (LLM_MODEL env var). It turns raw OCR text into a simple Hindi/Bengali explanation with amount, date, and action items.
It runs locally inside the same container via llama.cpp subprocess isolation, so there is no external inference bill and no data leaves the box.
The model is swappable in one config line: Qwen2.5-0.5B, Phi-3, or any GGUF-compatible model. I started with Phi-3 Mini but it OOM'd on the 0.1 CPU free tier, which is why SmolLM2-360M became the default.

Open harness + local inference

FastAPI + Uvicorn serve the app. Tesseract (pytesseract) does the OCR. Both are open source.
Heavy work runs in subprocesses with a sequential in-process lock, keeping peak memory under 512 MB on a single CPU.
Piper provides an offline Hindi/Bengali voice on-device, so the app still speaks when the network is down.

Open vision fallback

When Tesseract returns nothing (faded print, bad light), Gemma (gemma-4-26b-a4b-it) reads the photo directly through the free Google AI Studio API and returns structured JSON.
The vision prompt is locked to the user's chosen language, and the response is schema-validated before it reaches the TTS stage.

Why this architecture

My parents' data never needs to leave the server. On the SQLite profile, the app runs fully offline.
Every behavior swaps via environment variables: LLM_PROVIDER, LLM_MODEL, TESS_LANG, ELEVENLABS_API_KEY, GEMINI_API_KEY. No code changes required.
The monthly receipt is $0: Render free web service + Neon free Postgres + zero closed-API spend. ## Why Does Open Innovation Matter?  For my parents, "open" is not a buzzword — it is the only reason this exists at all.

Privacy without trust in a closed server

My parents' prescriptions, bank statements, and hospital bills never leave our infrastructure. With SQLite + local inference, the app works with the cable pulled. A closed API would require sending those papers to someone else's server, with no guarantee they won't train on them.

Model swap = accessibility swap

Hindi-first, Bengali-first, and English-first users all need the same app, but different voices and different LLMs. Open-weight GGUF models let me swap the brain in one line. Closed APIs would lock me into their pricing, their accents, and their privacy policy.

Cost = access

My parents are retired. A $20/month closed-API bill is not a viable long-term plan. SmolLM2-360M, Tesseract, Piper, Render free tier, and Neon free tier together cost $0. Open innovation made this project actually sustainable for the person it was built for.

What failed and what open alternatives made possible

Phi-3 Mini: 2.5 GB, OOM on 0.1 CPU. SmolLM2-360M: 360 MB, runs comfortably.
EasyOCR: pulled from the box for memory. Tesseract with sparse passes stayed under budget.
Render Postgres 30-day reset trap → Neon free Postgres, no reset.
Closed TTS APIs sounded robotic in Hindi/Bengali. ElevenLabs multilingual v2 + Piper on-device gave us a warm, female voice that sounds like home.

Prize Categories

Best Use of Render — deployed on Render free web service with Neon Postgres
Best Use of Gemma — Gemma 4 vision fallback via Google AI Studio free API (gemma-4-26b-a4b-it) with schema-locked JSON output
Best Use of ElevenLabs — ElevenLabs multilingual v2 TTS for Bengali/Hindi with Piper offline fallback

Cifrasync

Nayananshu Garai — Sun, 07 Jun 2026 14:12:41 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

CifraSync — a zero-dependency encrypted incremental backup tool written in C from scratch (200 KB binary, 31 source files, ~5000 lines). No Python, no Go, no npm. Just a single binary with chunk-based deduplication, RLE compression, HMAC stream cipher v2 (key separation, CSPRNG, 600K PBKDF2), incremental snapshots, remote sync, file-based mutual exclusion locks, and a colored interactive TUI.

The project started as a partially-built C backup scaffold with stubs and unfinished wiring. I completed all 7 commands (init, backup, restore, list, verify, prune, sync), added a server mode, wired compression and encryption end-to-end with key separation and cryptographically secure randomness, built an interactive menu, added file-based locking, and wrote a comprehensive README and docs. All 14 tests pass with zero compiler warnings.

Key technical features

Chunk-level deduplication — identical data across files/snapshots stored once
RLE compression — per-chunk, auto-decompressed on restore/verify
HMAC stream cipher v2 — Blob version 2 with key separation (enc_key ≠ mac_key), cryptographically random salt/nonce (CryptGenRandom / /dev/urandom), 600K PBKDF2 iterations, constant-time tag verification
Key cache — In-memory PBKDF2 cache eliminating redundant per-chunk derivation
Masked passphrase input — No echo on terminal (SetConsoleMode / getpass)
File-based mutual exclusion — flock/LockFileEx locks (EXCLUSIVE for writes, SHARED for reads)
Atomic manifest writes — .tmp + rename() crash safety
Journal replay — interrupted backups auto-resume
Cross-platform — same codebase compiles on Windows (MinGW), Linux, macOS
Interactive TUI — colored numbered menu, no flags needed for daily use
wake up cifra — one-command launcher after one-time setup.ps1

Demo

Build & Test

git clone https://github.com/N-Garai/CifraSync.git
cd CifraSync
mingw32-make release    # builds bin/cifrasync.exe (200 KB)
mingw32-make test       # 14/14 tests pass

Quick Demo (interactive mode)

# Create test data
mkdir C:\demo\source C:\demo\repo C:\demo\restored
"Hello world" > C:\demo\source\file1.txt
"Another file" > C:\demo\source\file2.txt
mkdir C:\demo\source\sub
"Deep file" > C:\demo\source\sub\deep.txt

# Launch interactive menu
cifrasync

CLI Usage

cifrasync init --repo PATH
cifrasync backup --source PATH --repo PATH [--compress] [--encrypt] [--label TEXT]
cifrasync list --repo PATH
cifrasync restore --repo PATH --snapshot ID --out PATH [--source-file PATH]
cifrasync verify --repo PATH
cifrasync prune --repo PATH [--keep-last N] [--older-than DAYS]
cifrasync sync --repo PATH --remote HOST:PORT   # pushes manifests + chunks to remote
cifrasync serve --bind HOST:PORT [--repo PATH]   # receives & stores sync data

The Comeback Story

Before : The project had the CLI scaffold, core storage and chunking layers, basic tests, and tools. But 3 of 7 commands were stubs (verify, prune, sync returned "unsupported"). Compression and encryption were logged but not applied. Snapshot listing showed bare filenames only. No journal replay, no atomic writes, no config auto-load, no single-file restore, no interactive mode, no launcher. The project needed documentation, polish, and a clear demo path.

After : Every command is fully implemented. Compression and encryption are wired end-to-end (RLE before store, HMAC seal v2 with key separation, auto-decompress on restore/verify). Encryption uses cryptographically random salt+nonce, 600K PBKDF2 iterations, masked passphrase input, and key separation (enc_key ≠ mac_key). File-based mutual exclusion locks prevent concurrent corrupting writes. Journal replay resumes interrupted backups. Atomic .tmp + rename() prevents partial snapshots. Config auto-loads on startup. The snapshot list shows rich details (ID, timestamp, file count, size, label). There's a colored interactive TUI, a serve command for remote sync, and a wake up cifra one-command launcher. The README is comprehensive with a full interactive mode reference table. All 14 tests pass with zero warnings.

Sync Protocol (full data transfer)

The sync now implements bidirectional chunk transfer via a custom TCP frame protocol:

HELLO — client announces itself, server responds with repo path
MANIFEST — client sends full snapshot metadata + serialized manifest file (all file/chunk references)
Missing chunk negotiation — server compares manifest chunk hashes against its local chunk store, returns list of only the missing hashes
CHUNK — client reads each missing chunk from local store and sends it as binary frame (64-byte SHA-256 hash + raw data)
BYE — clean disconnect

Only chunks the server doesn't already have are transferred, making re-syncs incremental. The server writes .snapshot metadata files, .manifest files, and stores chunks using the existing repository format. The client reads manifests from its local repo and sends chunk data on demand.

Key changes made:

Implemented verify (chunk re-hash), prune (snapshot deletion + orphan GC), sync (full manifest + chunk data transfer), serve (server mode with --repo for storage)
Wired RLE compression and HMAC encryption into the backup pipeline
Blob v2 with key separation — enc_key/mac_key derived via HMAC-SHA256 from master key; authentication tag computed with mac_key, stream cipher uses enc_key
Cryptographically secure randomness — replaced time()+clock() salt/nonce with CryptGenRandom (Windows) / /dev/urandom (POSIX)
PBKDF2 iterations: 10K → 600K — OWASP 2023 recommendation for SHA-256
Wired in key cache — per-session static cache avoids recomputing PBKDF2 per chunk
Masked passphrase input — SetConsoleMode disables echo on Windows; getpass on POSIX
Passphrase zeroization — passphrase buffer cleared in backup cleanup path
Wrong-passphrase now fails loudly — restore/verify previously silently produced garbage; now they return errors with log messages
File-based mutual exclusion — EXCLUSIVE lock for backup/prune/server-sync, SHARED lock for restore/verify/client-sync; cross-platform via flock / LockFileEx
Fixed Windows shared lock — LockFileEx now called for shared mode too (was a no-op)
Added journal replay on backup start
Added atomic manifest writes
Added rich snapshot listing with formatted columns
Added single-file restore (--source-file)
Added config auto-load
Built interactive TUI with colored ASCII menu
Created wake up cifra launcher (wake_up_cifra.cmd + setup.ps1)
Fixed platform detection (dynamic #ifdef instead of hardcoded)
Fixed verify with compressed chunks (decompress before hash check)
Added POSIX fallbacks for cross-platform support
Deduplicated 5 copies of path_join into shared cs_path_join
Fixed \r carriage return bug in interactive input (was corrupting paths on Windows)
Fixed NULL callback crash in journal.c
Wrote comprehensive README, after.md, and submission docs

My Experience with GitHub Copilot

I used GitHub Copilot throughout the completion process. Copilot was most helpful for:

Boilerplate code generation — writing repetitive CLI option parsing, path joining, and error handling patterns
Test writing — generating test cases and edge cases for unit tests
Documentation — drafting README sections, the submission post, and code comments
Bug finding — suggesting fixes for the \r carriage return issue and the verify decompression logic
Refactoring — suggesting how to deduplicate the path_join functions across 5 files into a single shared implementation

Every suggestion was reviewed, adjusted for the project's coding style and safety constraints, and validated against the test suite before being committed.

Demo Video

Watch the full walkthrough: https://youtu.be/IqonIOfXhFs

Repository: N-Garai/CifraSync