DEV Community: Rohit Purkait

TJ Holowaychuk left Express in 2014. 6,483 of his lines still run. Gemma called his commits "3,527 silent years".

Rohit Purkait — Thu, 29 Oct 2026 22:44:20 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine

What I Built

In Hindi, bhoot means ghost. It also means the past. Bhoot kaal is the past tense.

Every old repository has both. There are people who stopped committing years ago but whose code still runs every time someone types npm start. And there are files that were born, argued over for a few hundred commits, and deleted, with the reason written in a commit message nobody will read again.

Bhoot reads a repository's git history on your own laptop and finds both:

Still haunting: people who've been silent for a year or more, with how many of their lines git blame still finds at HEAD, and the oldest line of theirs that's still there.
The departed: deleted files, each with a tombstone: when it was born and who wrote it, when it died and who removed it, and its cause of death, which is the subject of the commit that deleted it.

Then a local Gemma writes each of them a two-sentence remembrance, in the spirit of Día de los Muertos: warm, a little eerie, never mocking. And then code checks every name, number, date and file in those two sentences against git, because, as it turns out, Gemma is very good at tone and quietly bad at facts.

The theme asked for something spooky, or something that honours the past. A graveyard for your codebase is both. The ghost in the machine is literal: TJ Holowaychuk hasn't committed to Express since February 2014, and 6,483 of his lines still run.

Demo

Walk the graveyards: bhoot-graveyard.vercel.app

expressjs/express: 12 ghosts, 30 graves, from 6,183 commits
request/request: the HTTP library half of npm leaned on, deprecated in 2020
jashkenas/underscore: born 2009

Light a candle for a ghost (it remembers, in your browser). Hover any badge to see what the checker verified, or what it threw out.

To raise your own:

ollama pull gemma3:4b
git clone https://github.com/codeswithroh/bhoot && cd bhoot
node src/cli.ts /path/to/your/repo --out graveyard
open graveyard/index.html

Code

codeswithroh / bhoot

भूत: ghost, and the past. The people who left your repo but whose code still runs, and the files that died, remembered by a local Gemma and checked against git.

Bhoot · भूत

In Hindi, bhoot means ghost. It also means the past.
Bhoot reads your repository's git history, finds both, and writes them a remembrance that git can vouch for.

Walk a graveyard · Quick start · How it works · Numbers · FAQ

TJ Holowaychuk hasn't committed to Express since February 2014. 6,483 of his lines still run.

Every old repository has ghosts like that: people who moved on but whose code didn't. It also has graves: files that were born, argued over for a few hundred commits, and deleted, with the reason buried in a commit message. Bhoot finds both on your own laptop. A local Gemma writes each a short remembrance in the spirit of Día de los Muertos, and code checks every name, number, date and file in it against git before it's carved.

View on GitHub

How I Built It

Git gives the facts

Everything Bhoot knows comes from four git commands: log (who committed when, and what they said), blame --line-porcelain at HEAD (whose lines are still here), log --diff-filter=D -M (which files died; -M so a renamed file doesn't count as a death), and show <commit>^:<path> (what a file said the day before it was deleted).

The first surprise was identity. In Express's history, TJ Holowaychuk is three people: TJ Holowaychuk, Tj Holowaychuk, and visionmedia, the name on his earliest commits. Counted separately, none of them is the top ghost. Bhoot merges identities with a small union-find: a commit joins its author's name and email, so any spellings that ever shared an email become one person. TJ came out as one ghost: 3,527 commits, silent since 2014-02-19.

Gemma writes the words

Gemma 3 4B runs in Ollama on my 8 GB MacBook. For each stone it gets the facts as plain lines (name, first and last commit, counts, the oldest surviving line or the start of the deleted file) and one instruction: two sentences, Día de los Muertos in spirit, use only these facts.

It's good at this. "Born July 13, 2010, this guide of 1,366 lines, crafted by Tj Holowaychuk, served as a helpful starting point. It faded April 16, 2012, a quiet end after 168 commits." Every fact there is right.

"3,527 silent years"

Here is what Gemma wrote for TJ on the first run:

TJ's spirit persists, 3,527 silent years woven into 6,483 lines of code, still running from 2009's initial release.

Every number in it is real. 3,527 is his commit count. It just isn't years.

That turned out to be the most common way Gemma got things wrong, and not the way I expected. I expected invented numbers. What I got was real numbers attached to the wrong thing: 32 commits became "32 contributors", 9 commits became "nine brief lives", 145 commits became "145 silent years", and a man who was silent for three years was "quietly maintained for three years". A checker that asks "is this number in the facts?" passes every one of those.

So the checker doesn't just look for numbers. It reads what each number counts:

A number has to count the right thing. "6,483 lines" passes because 6,483 is a line count. "3,527 years" fails because 3,527 is a commit count. A number in front of a noun the facts never count ("316 paths", "nine tests") fails too.
A year has to belong to the right event. "Born in 2012" must be the birth year; "removed in 2021" must be the death year.
A name has to have done what the sentence says. "Written by Roman" must be someone who wrote it; "laid to rest by Sebastian" must be the person whose commit deleted it.
Everything else must be in the facts: months, quotes, file names, function names, and any capitalised word that might be a name. "Sean Strom" can't be built out of the username seanstrom.

If a remembrance fails, Gemma gets one retry and is told exactly what was wrong ("it mentioned '3,527 silent years', which is not in the facts"). If it fails again, the stone carries plain dates instead. Every stone has a badge that says which happened.

My checker was wrong too

The first full Express run rejected Gemma's first attempt on 28 of 42 stones, and 15 ended up carrying plain dates. By my labels, only 8 of those 42 first attempts were actually false. Most of the rejections were my checker's mistakes, not Gemma's:

It thought July was a person. Capitalised mid-sentence, not in the facts as a word, so: an invented name. A file born on 2010-07-13 really was born in July.
It read "eighty-four commits" as "four commits", decided four was wrong, and threw out a true sentence.
On the held-out repo it rejected "David Chambers' code" because it didn't strip a possessive apostrophe, so "Chambers'" wasn't Chambers.

Each of those is now a test, next to the cases Gemma got wrong.

Testing it

I read every first attempt Gemma made and labelled it by hand: true, or saying something git contradicts. That includes a real number on the wrong thing. Then I scored the checker against my labels.

I built and tuned the checker on two repos, Express and request. Then I froze it in a commit (e2f3d9a) and ran a third repo it had never seen, underscore, once.

	Gemma's first attempts that were false	Caught by the checker	True attempts wrongly rejected
express + request (checker tuned on these)	22 of 78 (28%)	22 / 22	0 / 56
underscore, held out	3 of 16	3 / 3	1 / 13

On the held-out repo, every stone that ended up carved was true: 15 of them in Gemma's words, 1 in plain dates. The one wrongly rejected attempt was the "Chambers'" apostrophe bug; Gemma's retry passed, so nothing was lost.

Sixteen stones is a small held-out set, and I'm the only labeller. The labels, every attempt Gemma made, and the scoring script are all in the repo (eval/), so anyone can disagree with me line by line.

Family plots

request/request deleted sixteen proxy test files in one commit ("Merge all proxy tests into tests/test-proxy.js"). Sixteen near-identical tombstones made a boring graveyard, so files laid to rest by the same commit now share a family plot: one stone, with its siblings listed underneath.

Why Does Open Innovation Matter?

Because a git history is personal. It's who stayed late, who left, who rewrote whose code, and what they said when they deleted something. For an open-source repo that's public anyway. For your company's repo, or your team's, it isn't. Bhoot never sends it anywhere: git reads it, Gemma runs in Ollama on the same laptop, and the graveyard is one HTML file. A hosted model would mean uploading your team's entire commit history to remember the people in it.

Because I could make it reproducible. With the weights on my machine I fix the seed, so the same repo gives the same first attempts every time. That's what made the evaluation honest. When I fixed the checker, I re-ran it on exactly the same 78 attempts Gemma had already written and measured the difference, instead of hoping a new sample came out similar.

Because it costs nothing to remember everyone. Express has 387 people in its history. Writing a remembrance for each of them, with retries, is a lot of calls. Locally it's an evening of a laptop fan, with no budget to think about.

Because the model is swappable. BHOOT_MODEL=gemma3:12b uses a bigger Gemma, and the checker stays the same either way. The checker matters more than the model: a better model will make fewer "3,527 silent years", and the checker catches the ones it still makes.

The Spirit of It

I ran it on my own team's repo. Everyone was surprised first, and then it turned into a lot of laughing and teasing. Some of the team printed an image of the graveyard and put it up on their walls. Showing it to the whole team was a lot of fun.

Día de los Muertos isn't about mourning. It's about remembering people by name, with the details right.

That's what made the checker matter more to me than the prose. A stone that says "Born in 2012" when the file was born in 2011 isn't a remembrance. It's a mistake with a nice font. Getting the small facts right, the year, the line count, the name of the person who wrote it, is the part that honours someone.

Some of what the graveyards remember:

Express's original docs: born in July 2010, written by TJ, deleted in April 2012 by a single commit that just says "removed old docs". It took 31 files with it.
request/request's last commit, in February 2020, fixed a typo in its own deprecation notice.
Jeremy Ashkenas's oldest line still in underscore is from 2009, the year the library was born: a test fixture in test/arrays.js, var list = [1, [2], [3, [[[4]]]]];.

Prize Categories

Best Use of Gemma. Gemma 3 4B runs locally through Ollama and writes every remembrance. A checker holds it to git's facts, scored against hand labels, with a held-out repo run once on a frozen checker.

'Baad mein' means later. Gemma reads the WhatsApp chat you keep with yourself, and tells you what you can forget

Rohit Purkait — Sat, 24 Oct 2026 02:45:49 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

Almost everyone I know in India has a WhatsApp chat with themselves. WhatsApp even made it official: "Message yourself".

It's where later goes. A YouTube link you'll watch this weekend. "dahi, bread aur 2 maggi". "Raju ko 500 dena hai". "kal 9 baje bank jaana hai KYC ke liye". An address you'll need once. A recipe from Ma. The wifi password. An OTP from March that you never deleted.

Baad mein dekhenge. We'll see later. Later never comes, the chat gets longer, and every few weeks you scroll up through five months of your own notes, feel bad, and scroll back down.

So I built Baad Mein (बाद में, "later"). You export that chat, and Gemma reads it slowly, inside your browser tab, while you sleep. In the morning you get one card:

Today and this week: what's due, with dates worked out by code, never guessed by the model
Money: who owes you, who you owe, how much
To buy: every shopping note from the last three weeks, merged into one list
Not sure: the notes it refuses to guess about, with the reason
Delete these from the chat: OTPs, card numbers, Aadhaar, PAN and passwords, masked
Let go: old links, dead to-dos and stale shopping lists, with permission to forget them

That last one is the sloth part. Most of what's in a "later" pile doesn't need doing. It needs someone to tell you it's okay to stop carrying it.

Demo

Live: baad-mein.vercel.app

Press See an example for a finished card straight away. It's a made-up 100-note chat, and the answers are Gemma's real replies, recorded from a run on my laptop and replayed through the same code. Or press Read my chat and give it your own export (Chrome or Edge on a laptop; Gemma 4 E2B downloads once, about 2 GB). If you don't want to use your own chat, there's a made-up export to download under "How to get your chat out of WhatsApp".

Tap any line on the card and it shows the note it came from, word for word, with the day you wrote it.

Code

codeswithroh / baad-mein

Your WhatsApp chat with yourself, read slowly by Gemma 4 in your browser. One card in the morning: what's due, what to buy, who owes what, and what you can let go.

Baad Mein (बाद में, "later")

Live: https://baad-mein.vercel.app · press See an example, or read your own chat.

Everyone has a WhatsApp chat with themselves. Links, "dahi bread aur maggi", "Raju ko 500 dena", an OTP from March. Things you'll deal with later.

Baad Mein reads that chat slowly, with Gemma 4 running inside your browser tab, and gives you one card in the morning:

Today and this week: what's due, with dates worked out by code, not guessed by the model
Money: who owes you, who you owe, with amounts
To buy: every shopping note from the last three weeks, merged into one list
Not sure: notes it won't guess about, with the reason
Delete these from the chat: OTPs, card numbers, Aadhaar, PAN and passwords, masked
Let go: old links, dead to-dos and stale lists you can stop carrying around

Nothing is…

View on GitHub

How I Built It

Slow and steady, on purpose

Gemma 4 E2B runs in the tab through MediaPipe's LLM Inference on WebGPU. It reads eight notes at a time, and every answer is saved to IndexedDB the moment it arrives.

That makes the slowness free. You can start it at night with the laptop on charge and walk away. If the tab closes, the laptop sleeps or the battery dies, open the same chat again and it picks up where it stopped. I tested exactly that: closed the tab at 55 of 100 notes, reopened, and it said "4 batches picked up from last time" and carried on to the same card.

On my 8 GB MacBook it's about 5 seconds per eight notes, so a 100-note chat takes under a minute, and a few thousand notes is a slow evening. Nobody has to watch it.

Gemma copies. Code reads.

A 2B model is good at "what kind of note is this?" It's bad at arithmetic, calendars and money. So the work is split in three:

your chat export
  ├─ code     secrets (OTP, card, Aadhaar, PAN, passwords) → "delete these"
  │           bare links, empty notes → settled, no model needed
  ├─ Gemma    for each note: todo / buy / money / read / keep / done / noise,
  │           and COPY the words that matter ("what", "when", "who")
  └─ code     checks every copied word is really in the note
              works out every date, every amount, who owes whom
              closes a to-do when a later note says it's done
              marks anything that doesn't add up as "not sure"

Gemma never sees your OTPs. Plain code finds them first, with checksums so a phone number or an order ID doesn't count: Luhn for card numbers, the Verhoeff check UIDAI uses for Aadhaar, the PAN pattern, and the words that announce a password or PIN. Those notes go straight to the "delete these" list, masked, and never reach the prompt.

Gemma never writes a date. It copies the words ("kal subah 8 baje", "monday ko", "12 tarikh", "parso") and code works out what they mean from the day the note was written. That part came from an earlier project of mine, Pakka, where I learned that kal means both tomorrow and yesterday in Hindi and only the verb tells you which.

Gemma never decides who owes whom. It copies the name. Code reads the direction from the words: dena, bhejna, wapas karna, dite hobe means you pay; lena, se lena, nite hobe, debe, owes me means you get paid. If the words don't say, the note goes to "not sure".

And Gemma's copies are checked. If the words it returns aren't actually in your note, the card shows your note as you wrote it and says why. On the held-out set, Gemma rewrote instead of copying 0 times out of 49.

Why code does the dates: 8 out of 19

I tested the obvious alternative. Same 19 to-dos with due dates, the date each was written right there in the prompt, and Gemma asked to give the due date itself.

Gemma: 8 of 19 right. Eight of its answers weren't even valid dates ("2026-19-Oct-2026"). "renew PUC kal", written on 20 October, came back as the 19th.

Code, from the words Gemma copied: 16 of 19 right, 2 marked "not sure" instead of guessed, 1 wrong. The two "not sure" ones are honest: "bike service next sunday", written on a Tuesday, could mean the coming Sunday or the one after, so the card asks.

Testing it

I wrote two made-up "chats with yourself" in the mix I actually see: English, Hinglish and Banglish, links, lists, money, IDs, half-typed nonsense. Every note is labelled by hand.

I tuned the prompt on a 40-note dev set only, then froze it in a commit before running the 100-note held-out set once. Same model and runtime as the app: Gemma 4 E2B in Chrome with WebGPU, on an 8 GB MacBook, driven by a script so the run is repeatable.

Held-out, 100 notes
Kind of note right	95 / 100
Due dates right	16 / 19 (2 "not sure", 1 wrong)
Money direction right	9 / 9
Secrets caught before Gemma	7 / 7
Gemma rewrote instead of copying	0 / 49
To-dos closed by a later "done" note	6
Time	49 seconds

The raw runs, every reply included, are in eval/results/ in the repo.

Two bugs worth telling

Gemma broke its own JSON, and a whole batch vanished. On one dev run, five notes in a row came back as "Gemma didn't say what this is". The reply looked fine at a glance. It wasn't: Gemma had written "who=""" instead of "who":"", and one bad key made the whole array unparseable. The classification inside was perfect. Now the reader repairs that slip before parsing, there's a test for it, and the dev set went from 36 to 40 out of 40.

Netflix was tagged as X. The link reader checked whether a URL contained x.com. So does netflix.com. A word boundary fixed it, and a test keeps it fixed.

What it can't do yet

It once read a bill as already paid. "pay credit card bill 22nd" came back as done, which would quietly hide a real bill. That's the mistake I like least, and the next thing I'd fix: a "done" note should need a past-tense verb in the note itself before code believes it.
"end of month" isn't a date code understands yet, so "car PUC expires end of month, renew" goes to "not sure".
Plans read as tasks. "Pujo plans: Saturday Maddox Square, Sunday Bagbazar" is information, but Gemma filed it as a to-do.
After the held-out run I fixed one bug it exposed: when Gemma copied the wrong words as the date ("office party ke liye"), code gave up instead of reading "30 oct" from the note. Code now reads the note's own day words in that case. The numbers above are from before the fix.

Why Does Open Innovation Matter?

Because this is the most private chat on your phone. The chat you keep with yourself is where people paste the things they'd never send anyone else: Aadhaar numbers, bank account numbers, the netbanking password "just for now", OTPs. Sending that to a hosted model, to sort it, means handing a stranger the exact pile you'd most like deleted. Baad Mein reads it in your own browser tab. Once the model is downloaded, reading your chat makes no network calls at all. Nothing is uploaded, there's no account, and there's no server to leak.

Because "slow" only works when it's free. An overnight job over a few thousand notes is a lot of tokens. On a paid API, "let it run slowly while you sleep" is a bill. On an open model on your own laptop, it costs some electricity, and there's no reason to rush it.

Because I could make it boring. With the weights on my machine, I run Gemma greedy (top-k 1, temperature 0), so the same chat gives the same card every time. That made it possible to test properly: a frozen prompt, a held-out set, a recorded example that replays exactly. It also means the example in the app isn't a mock-up. It's Gemma's real output.

Because the rules around the model are mine. The secret detection, the date reader, the money words in three languages and the "let go" rules are plain code anyone can read and change. Where an open model ends and my code begins is visible line by line, so when it's wrong, I can say exactly which half was wrong.

The Lazy Payoff

My first user. I handed Baad Mein to someone this week who lives in WhatsApp. It's the app they open every day, so their chat with themselves is where the day's reminders end up. After using it, they told me it's genuinely useful: it reminds them of the daily things they'd parked there, and it has helped their productivity. That's the whole point. The reminders were already in WhatsApp; they just needed someone to read them back.

The numbers. The made-up chat in the example covers five months: 100 notes. Reading through it yourself means scrolling, re-reading, deciding, and still forgetting half.

Baad Mein read it in 49 seconds, unattended, and turned it into:

20 things that need you: 5 due today or overdue, 4 this week, 9 about money, 2 it wasn't sure about
16 things to buy, merged from six separate lists
20 things you can let go, with the reason for each
7 secrets to delete from the chat

You read one card instead of five months. Tap anything you don't trust and see the original note. Then press Copy as a WhatsApp message and send the card back to yourself, to the same chat, where it belongs.

Prize Categories

Best Use of Gemma. Gemma 4 E2B runs fully in the browser through MediaPipe on WebGPU. It's held to copying, never computing, and scored on a held-out set with the prompt frozen first.

'Kal' means yesterday and tomorrow. I built home bakers a WhatsApp order sheet that never guesses which.

Rohit Purkait — Sun, 18 Oct 2026 01:05:12 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge: Week 2 (Side Hustle).

In Hindi, kal means tomorrow. It also means yesterday.

"Kal shaam 6 baje 1 kg truffle chahiye" is an order for tomorrow evening. "Kal jo cake liya tha, sabko pasand aaya" is a thank-you for a cake that already got eaten. Same word. Only the verb tells you which.

If you've ordered a birthday cake in India lately, there's a decent chance it came from someone's home kitchen, and that the whole order happened on WhatsApp: a flavour, a weight, "eggless please", a name to pipe on top, a GPay screenshot. Home bakers run real businesses this way. The order book is the chat list. The night before a busy day means scrolling through every chat, writing tomorrow's cakes into a notebook, and hoping nobody said "actually 1.5 kg kar do" three messages down.

So I built Pakka (Hindi for "confirmed, for sure"). You export the chats from WhatsApp and add them. Gemma 4 reads them on your own phone and Pakka turns them into tomorrow's bake sheet. The one rule I held it to: when it isn't sure, it asks you. It doesn't guess.

What I Built

Pakka is a web app for home bakers who take orders on WhatsApp.

In WhatsApp: open a customer's chat → ⋮ → More → Export chat → Without media. Do that for each chat with an order.
Add the files to Pakka (plain .txt or the .zip an iPhone makes).
Gemma 4 E2B reads each chat in your browser and Pakka builds a bake sheet grouped by day: time, customer, cake, weight, eggless or not, the message for the top, price, advance, and what's still due.
Anything Pakka isn't sure about gets an amber note on the card saying exactly why. One tap shows the chat lines it came from.
Each order has a Copy confirmation button. It writes a short WhatsApp message back to the customer ("1 kg chocolate truffle (eggless), Sun 19 Oct, 6:00 pm, 'Happy Birthday Riya', balance ₹700. Sab sahi hai?"). The customer is the last check.

Nothing is uploaded. No account, no server, no API key. Customer names, phone chats and home addresses stay on the baker's phone.

Who would pay for this? A home baker with a dozen orders a week. The work Pakka replaces is the late-night notebook session and the occasional disaster: a cake made with egg for a family that doesn't eat egg, a cake ready a day late, a name spelled wrong in icing. One remade cake costs more than a year of a small app. I'd charge a one-time ₹299, or ₹49 a month with backup across devices. That works because there's no per-chat cost to me: the model runs on the baker's phone.

Demo

Live: https://pakka-gamma.vercel.app

Try 18 sample chats runs Gemma for real in your browser (WebGPU: Chrome or Edge on a laptop or a recent Android phone, Safari 26). The first run downloads the model once, about 2 GB.
No time for a 2 GB download? Open https://pakka-gamma.vercel.app/?replay. It replays the replies Gemma gave in my test run through Pakka's checker, live, with the chats re-dated to today.

Code

codeswithroh / pakka

A home baker's WhatsApp orders, turned into tomorrow's bake sheet. Gemma 4 E2B reads the chats on the phone; code checks every detail.

Pakka

A home baker's WhatsApp orders, turned into tomorrow's bake sheet. Gemma 4 reads the chats on the baker's own phone. Code checks every detail against the chat.

Live: https://pakka-gamma.vercel.app · recorded run, no download: https://pakka-gamma.vercel.app/?replay

In Hindi, kal means tomorrow and also yesterday. "Kal shaam 6 baje 1 kg truffle chahiye" is an order "Kal jo cake liya tha, sabko pasand aaya" is a thank-you. Pakka's rule: when it isn't sure, it asks the baker. It doesn't guess.

How it works

Export chats from WhatsApp (⋮ → More → Export chat → Without media) and add the .txt / .zip files.
Gemma 4 E2B runs in the browser (MediaPipe LLM Inference on WebGPU, ~2 GB, downloaded once and cached) It finds each order and copies the exact words for each detail. It never converts or calculates.
Code does the reading, and every step is unit-tested
- findQuote()…

View on GitHub

How I Built It

The stack is small on purpose: TypeScript and Vite, no framework, no backend, deployed as static files on Vercel.

Piece	What it does
Gemma 4 E2B (`litert-community/gemma-4-E2B-it-litert-lm`, web build)	Reads each chat and copies the words for each detail
MediaPipe LLM Inference on WebGPU	Runs Gemma in the browser. Weights stream from Hugging Face and are kept in the Cache API, so later visits don't download them again
`whatsapp.ts`	Parses Android and iPhone export formats, multi-line messages, `.zip` exports
`when.ts`	Turns "kal shaam 6 baje" into a date and a time, and says when it can't
`fields.ts`	Turns "aadha kilo", "dedh kg", "₹1,200", "500 bhej diya", "bina ande ka" into values
`extract.ts`	The prompt, plus the checker that holds Gemma's answer up against the chat

Gemma copies. Code reads.

The obvious design is to ask Gemma for the finished answer: a date like 2026-10-18, a weight like 1.5, eggless: true. I tested that design as the baseline. It reads beautifully. Eggless, advance paid, the name for the cake: all right. Then you check the dates. Rahul thanked the baker for yesterday's cake ("kal jo red velvet liya tha…") and in the next message ordered a pineapple cake for Tuesday. Gemma put the pineapple cake on tomorrow. Ishita asked for "kal", heard back "kal full hai, parso chalega?", and agreed to parso. Gemma put it on tomorrow too.

So I split the job. Gemma does the part small models are good at: find the order and copy the exact words for each detail. The prompt says it plainly:

For each order, copy the customer's or baker's EXACT words for each detail,
character for character, from one message. Do not translate, explain,
convert or calculate anything.

What comes back looks like this:

{"item": "chocolate truffle", "size": "1 kg", "eggless": "eggless please",
 "day": "kal shaam", "time": "6 baje", "cake_message": "upar likh dena \"Happy Birthday Riya\"",
 "price": "1200 hoga", "advance": "500 advance bhej diya"}

Then code takes over, and every step is something you can test:

Is the quote really in the chat? findQuote() searches the messages (newest first, ignoring case and punctuation, allowing for a small model that trims a word). If the words aren't there, the detail is dropped and the card says "Gemma wrote '…', but those words aren't in the chat." Gemma can't add a detail that isn't in the chat. It can only point at one.
What do the words mean? "aadha kilo" is 0.5 kg. "1.2k" is ₹1,200. "egg chalega" means with egg. Each parser returns null instead of guessing.
Did they change it later? If a later message mentions a different size, the card asks: "A later message says 1.5 kg. Did they change it?"

Kal is two days

Gemma never decides what "kal" means. It copies "kal shaam" and code works out the day, relative to when that message was sent, not when you open the app.

For "kal" and "parso" (which also points both ways: the day before yesterday, or the day after tomorrow), when.ts looks at the clause the word sits in. Past-tense markers (tha, liya, diya, bheja, aaya) push one way, request markers (chahiye, dena, ready, pickup, tak) push the other:

if (twoWay && isHindi) {
  const clause = clauseOf(message, quote).replace(/\bke\s+liye\b/g, ' '); // "ke liye" = "for"
  const past = PAST.test(clause);
  const future = FUTURE.test(clause);
  if (past && !future) return result(at(-days), false, `"${word}" here sounds like the past…`);
  if (past && future)  return result(at(days),  false, `"${clause}" mixes past and future…`);
}

It works per clause because real messages mix tenses: "kal 4 baje de dena, 500 bhej diya" has a past verb in it (bhej diya, "I sent"), but in a different clause from kal. Splitting on commas and aur / par / lekin keeps that order on the sheet for tomorrow.

The same file handles the other ways a day gets named: "Sunday" sent on a Sunday (today, or next week?), Indian-English "next Sunday" (usually the coming one, not always), "25th", "25 tarikh", "3rd" when it's already the 17th (next month), and Devanagari (कल शाम 7 बजे). Times without am/pm ("6 baje") get read from the words around them (shaam, subah); when there are none, Pakka guesses afternoon and tells you it guessed.

Testing it

I wrote 18 WhatsApp chats by hand to test it. They're modelled on how orders to home bakers read, but every chat and name is made up. Most are ordinary orders. Some are traps: "kal" about yesterday, "parso" about a complaint, a size changed the next morning, an order cancelled, a customer only asking prices, Devanagari script, two orders in one chat, "next Sunday", and a weekday named on that same weekday.

I ran every chat through Gemma 4 E2B twice, in the Chromium browser pane on a Mac mini (M4, 16 GB), with the same runtime the app uses:

Gemma alone: told today's date and asked for the finished values.
Pakka: Gemma copies the words, and the checker and parsers above do the rest.

Main set: 18 chats, 16 orders.

	Gemma alone	Pakka
Delivery day right	4 / 16	16 / 16
Delivery day confidently wrong	8	0
No day at all	4	0
Size	13 / 16	16 / 16
Time	10 / 15	14 / 15
Price	13 / 16	16 / 16
Eggless	16 / 16	16 / 16
Advance paid	14 / 14	14 / 14
Text for the cake	15 / 16	15 / 16
Orders that weren't orders	3	0

"Right" for the two ambiguous chats ("Saturday" sent on a Saturday, "next Sunday") means the card asks the baker. Gemma alone has no way to say "not sure" in that format, so those two count against it by design. Take them out and Gemma alone still gets 10 of the other 14 dates wrong or leaves them blank. Pakka gets 0.

Now the part I have to be upfront about. Pakka's first run on this set wasn't 16/16. It was 15 right, 1 asked, 0 wrong, with 3 orders that weren't orders: a customer who only asked the price, an order cancelled the next morning, and a size change that Gemma returned as two separate orders. I fixed those with three chat-level rules in code (a price question with no day and no money is an enquiry; a later "cancel kar do" takes the order off; a repeated item is one order with the latest details), plus one bug: "ke liye" ("for") was being read as the past-tense liye. Then I re-scored the same recorded replies. That's tuning on the test set, so I wrote 8 new chats after freezing the code and ran them once:

Held-out set: 8 new chats, 7 orders, code frozen, run once.

	Gemma alone	Pakka
Delivery day right	3 / 7	6 / 7
Delivery day confidently wrong	4	0
Asked the baker	0	1
Size	6 / 7	7 / 7
Price · advance	7 / 7 · 7 / 7	7 / 7 · 7 / 7
Orders that weren't orders	0	0

The one it asked about was a real bug: "the day after tomorrow" contains the word "tomorrow", so when.ts saw two different days and asked which one. It failed the safe way. That's fixed now (with a test), and the held-out set re-scores 7/7. The numbers in the table are from before the fix.

The row I care most about is confidently wrong dates: the cake is on the sheet for the wrong day and nothing warns you. Across both sets, Gemma alone got 12 delivery days confidently wrong, and 5 of those 12 were "tomorrow": for a Tuesday, for a Monday, for parso twice (once written परसों), and for a parso agreed right after a kal was turned down. When it isn't sure, a small model reaches for tomorrow. Pakka got 0 wrong. Same model, same chats. The only difference is who does the date arithmetic.

Here's the Rahul chat on Pakka's sheet. The highlighted lines are where each detail came from. The "kal" message about yesterday's cake isn't highlighted, because nothing on the card came from it:

The eval page ships with the app (/eval.html), and every raw Gemma reply is committed in eval/results/. node eval/rescore.ts <file> re-scores them with the current checker, no model needed.

Speed: 2.4 seconds per chat (median) on the M4 once the model is loaded. A dozen chats takes about half a minute. Fine for the night before, not instant.

What it can't do yet

The test set is mine. I wrote those chats, so they reflect what I thought to test. Real chats will be messier: voice notes, photos of reference cakes, orders split across days.
Voice notes are skipped. Lots of orders arrive as voice notes. Gemma 4 E2B can take audio, so that's the next step, but I haven't built it.
Needs WebGPU and 2 GB. Older Android phones can't run it. The recorded replay shows what Pakka does, but it can't read your chats on those phones. And in the browser I tested in, the cached model didn't survive a reload, so it downloaded again. Browsers that cap storage per site will do the same.
Exporting is a chore. One chat at a time from WhatsApp. On Android, a share target that receives the export directly would remove a step.
It doesn't know your menu or prices. It reads what was said. It doesn't check that a 1.5 kg truffle is ₹1,350.

Why Does Open Innovation Matter?

Because the chats are private. A baker's WhatsApp has customers' names, phone numbers, home addresses, their kids' names and birthdays. With an open-weight model running in the browser, none of it goes anywhere. I didn't have to write a privacy policy to make that true. It's just how the app works.

Because the margins are small. A home baker makes a few hundred rupees on a cake. A hosted model would charge for every chat, every night. Gemma on the phone costs nothing per chat, so I can sell this for a one-time price.

Because the kitchen Wi-Fi is bad. Once Gemma is on the phone, reading chats needs no connection at all.

Because I could open it up and fix it. When Gemma wrote finished values, I couldn't see why it got a date wrong. With an open model, I could change what I asked of it, run every test chat through it twice on my own machine for free, and move every judgement I didn't trust out of the model and into code a person can read and test.

Prize Categories

Best Use of Gemma. Gemma 4 E2B runs fully in the browser (MediaPipe LLM Inference on WebGPU), reading Hinglish and Devanagari WhatsApp chats on the baker's own device. The design is built around what a 2B-effective model is good at (finding and copying) and keeps it away from what it isn't (date arithmetic in a language where one word means two days), with an eval to show the difference.

If you know a home baker who lives in WhatsApp, send them the link, and tell me what Pakka got wrong.

I built an AI that only works when my phone is in my pocket

Rohit Purkait — Wed, 07 Oct 2026 05:56:15 +0000

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

What I Built

Every "go outside" app I have tried wants me to look at it once I'm outside: a map, a streak, a badge, a feed. I wanted the opposite: an app that is finished with me before I reach the front door.

Drift is a walk with no destination. You choose how long and a mood (quiet, colors, old things, sounds). Gemma 4, running in your browser, writes a short set of playful rules. An open-weight voice reads them to you, one at a time, while the phone sits in your pocket:

"Trace the outline of the oldest brick you can find with your hand."
"Follow the faint scent that seems to remember rain."
"Stand still until the distant, muted sound settles into your bones."

(Those are real rules Gemma wrote during testing.)

The idea is borrowed from the dérive (French for "drift"), a practice from the 1950s Situationists in Paris. They walked cities by following rules instead of routes, to notice what a destination hides. Seventy years later we have a better excuse never to look up, so I gave the rules to an AI and took the screen away.

When you get home, you talk for a minute about what you noticed. Whisper transcribes it on the device, and Gemma writes it up as an entry in a field notebook. Each entry leaves one line of memory, so the next drift leans toward what you enjoyed.

There is one number Drift actually cares about: how many seconds your screen was on during the walk.

Meet Pip 🦔, who keeps you company before and after. Pip watches your finger, falls asleep while you walk, and gets star-eyed if you barely looked at your phone.

I took it outside

I opened Drift on my iPhone in Safari, and Gemma 4 wrote me a drift called The Quiet Current, right there on the phone. Then I went out and walked for about ten minutes.

I noticed things I hadn't noticed before: how the leaves were moving, and how the wind felt when it touched me. It was hot out, but there was a cool edge underneath the heat. It's October, and even in the sun I could feel a little of the cold that's coming. It was a very engaging feeling, and honestly I can't quite put it into words.

Then I came home and looked at what Drift had recorded, and it caught me out:


Drift	The Quiet Current
Device	iPhone, Safari, Gemma 4 running on the phone
Actually walked	about 10 minutes
Walk the app counted	2 minutes (I ended the drift early and kept walking)
Screen on	2 min 5 sec, the whole time it was counting
Notebook entry	"Thank you."

Two honest lessons from one short walk:

I didn't lock my phone. I kept Drift open in my hand, so the screen-time counter did exactly its job and recorded that the screen was on the whole time. The best part of the walk happened after I stopped looking at the app. That's the whole thesis of Drift, demonstrated on its own author.
My notebook entry just said "Thank you." That's a well-known Whisper failure: when it hears silence or almost nothing, it outputs "Thank you." (it was trained on a lot of subtitles). Drift saved that as my notebook entry. It now checks whether a recording is too short or too quiet, drops Whisper's silence phrases, and asks you to try again. There's a test for it with real Whisper.

Next time the phone goes in my pocket.

What a drift actually looks like

Here is a real one, written by Gemma 4 E2B running on WebGPU in my browser. I picked 30 minutes and the mood old things. Gemma wrote this in 11.5 seconds:

Echoes in the Cobblestones

Find the object with the deepest shadow beneath a large leaf.

Listen intently to the rhythm of the oldest wood.

Touch the texture of the wall that feels the longest.

Follow the faint scent that seems to remember rain.

Stand still until the distant, muted sound settles into your bones.

Allow your gaze to simply rest on the most enduring shape nearby.

None of these need a map, and none of them could be followed while looking at a phone. That's the point. You can't do "touch the texture of the wall that feels the longest" from a screen.

Every time you press Prepare the rules are new. Other drifts Gemma wrote while I was building: The Echo Chamber Wander, Chromatic Descent, Dust & Echoes.

Then Kokoro reads them in a calm voice, with a soft chime before each rule and minutes of silence after it. The rendered walk for The Echo Chamber Wander came out at 31 minutes of audio, from a single file. On the deployed site I watched the counter tick from "Starting" to "Rule 1 of 6" while the audio played, with the page doing nothing else.

	Time on my laptop (Apple GPU, WebGPU)
Gemma 4 writes a drift	11.5 s
Gemma 4 writes a notebook entry	2.2 s
First-time model download (2 GB)	~11–14 min on my connection
Network needed during the walk	none

Demo

🌿 Try it: drift-three-nu.vercel.app · Code: github.com/codeswithroh/drift. I've run it on an iPhone (Safari) and a MacBook (Chrome). It needs WebGPU: Chrome or Edge, or Safari 26+. The first visit downloads about 2.5 GB of models, so use Wi-Fi.

Choose	Prepare	Walk	Screen time	Notebook

Code

codeswithroh / drift

A walk with no destination. On-device Gemma writes the rules, Kokoro reads them, your phone stays in your pocket.

Drift

A walk with no destination. An open-weight AI writes the rules, an open-weight voice reads them, and your phone stays in your pocket.

Try it · How it works · Run it · Tests

Why

Every "go outside" app I have used wants me to look at it outside: a map, a feed, a badge. Drift takes the opposite approach. You spend about 30 seconds on the screen before you leave, and then the phone goes in your pocket.

It is based on the dérive (French for "drift"), a 1950s Situationist practice: walk a city by following playful rules instead of a destination, and notice what the route would have hidden. Drift asks Gemma to invent those rules for you, has an open-weight voice read them, and counts how many seconds your screen was on while you walked.

Features

🌿 Rules, not routes. Gemma writes a fresh drift for…

View on GitHub

How I Built It

Drift is a static web app: Vite and TypeScript, no framework, and no backend at all. Every model runs on your device.

Job	Open model	How it runs
Write the rules + the notebook	Gemma 4 E2B (web build, 2 GB)	MediaPipe LLM Inference on WebGPU
Read the rules aloud	Kokoro-82M	`kokoro-js`, WebGPU or WASM
Listen to your debrief	Whisper base	`transformers.js`, WebGPU or WASM

The trick: the whole walk is one audio file

My first idea was to speak each rule on a timer. That doesn't work: a locked phone suspends a web page's timers and background GPS, so the app goes to sleep with you.

Audio, though, keeps playing. So Drift does all the work before you leave. Gemma writes, say, 7 rules. Kokoro speaks each one. Then I stitch them into a single WAV file: a soft two-note chime, the spoken rule, then minutes of silence while you walk, all repeated.

for (const [i, step] of drift.steps.entries()) {
  const raw = await tts.generate(step.say, { voice: 'af_heart', speed: 0.95 });
  if (i > 0) push(chime());
  push(resample(toMono(raw.audio), raw.sampling_rate, 16000));
  push(new Float32Array(Math.round(step.walkSeconds * 16000))); // walk
}

You press play, lock the phone, and the next 30 minutes need no wake-ups, no GPS and no signal. The screen-time counter is just the Page Visibility API: every second the page is visible during the walk counts against you.

Things that broke (and what I learned)

I wrote end-to-end tests with Playwright that drive the real app with real models: real Gemma, real Kokoro, and a fake microphone playing recorded speech so Whisper has something to transcribe. They found bugs I would have shipped:

Gemma 4 returned an empty string. MediaPipe passes your prompt to the model as-is, and Gemma 4 only answers inside its chat template (<|turn>user … <turn|><|turn>model). Without it, every drift silently fell back to my built-in rules. One line fixed it, and it was invisible until a test asserted that the title wasn't the fallback title.
The 2 GB model didn't fit. Some browsers cap a site's storage below 2 GB. My cache.put() failed quietly, so the app re-downloaded Gemma on every visit. Now it checks navigator.storage.estimate() first and tells you honestly when the model can't be kept offline. The walk itself still never needs a network.
Small models can't add up. Gemma's durations rarely total the 30 minutes you asked for, so Drift rescales the silences to fit exactly. Gemma also loved copying my example rules word for word, so the prompt now asks it to invent its own.
The notebook made things up. My tests play a recorded debrief through a fake microphone: "I followed a yellow bicycle past a bakery. Then I stood under a huge old tree and listened to the wind in the leaves." Whisper transcribed it correctly. But with the smaller laptop fallback model (Gemma 3 4B via Ollama), the notebook entry came back mentioning "the coarse, warm texture of the brick wall against my palm." I never said anything about a wall. Gemma 4 had the opposite problem at first: it copied the transcript word for word. The prompt now asks for a rewrite in a naturalist's voice and forbids inventing sights. A notebook that lies about your own walk is worse than no notebook.
"Thank you." My first real walk produced a notebook entry that was just Whisper's silence hallucination (see above). Silent recordings are now rejected before they reach the notebook.
"Rule 5 of 4." The progress counter included the intro and outro clips. A classic.

Pip

Pip is drawn as two 3×3 sprite sheets (nine head directions, nine expressions), adapted from the MIT-licensed page-mascot by Kamran Ahmed. I ported the React component to plain TypeScript and gave Pip a mood for every screen. It's a small thing, but it makes a 2 GB download feel like waiting with a friend.

Why Does Open Innovation Matter?

Drift could not exist as a closed-API app, for three reasons.

1. It has to work with no signal. The walk happens where the network doesn't reach: parks, trails, the back streets the rules send you down. With an open-weight model the rules are written on your phone before you leave, and the walk needs nothing at all.

2. Your voice stays yours. The debrief is a recording of you, outside, saying what you noticed. Sending that to someone else's server to be transcribed and summarized would make me uneasy, so with Whisper and Gemma in the browser it never leaves the phone. There's no account, no API key, and no database. There is nothing to leak because there is nothing to collect.

3. It costs nothing to run. Drift is a static site. Every walk is computed by the walker's own device, so 10 users or 10,000 cost me the same: zero. A closed-model version would need a backend, a bill, and eventually a subscription. That's a strange thing to charge for in an app whose whole point is using your phone less.

Open models also let me make design choices a hosted API never would: swap Gemma for a smaller model on older phones, pick the voice, change exactly how the notebook is written, and read the source of every layer when something breaks (see "Gemma 4 returned an empty string").

Prize Categories

Best Use of Gemma. Gemma 4 E2B runs entirely in the browser on WebGPU via MediaPipe. It writes every drift, writes every notebook entry, and keeps the memory that shapes the next walk.

Thanks to the Gemma, LiteRT, Kokoro, Whisper and transformers.js teams for making all of this run in a browser tab, and to Guy Debord for the idea, 70 years early. 🌿

My mom reads Bengali, not English. So I built her a reader that catches scams, on open-weight Gemma.

Rohit Purkait — Sun, 04 Oct 2026 16:41:19 +0000

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

What I Built

Last month Ma forwarded me a WhatsApp message saying her SBI account would be blocked unless she updated her KYC. She hadn't clicked the link. She had called the number.

My mom reads Bengali. So do my grandparents. Most of the paper that runs their lives doesn't: electricity bills, bank letters, the strip on a blood-pressure tablet, and the steady stream of "Dear Customer, your account will be BLOCKED today" messages that every Indian parent's phone collects.

So every one of those ends up as a photo sent to me, with "এটা কী?" (what is this?). If I'm in a meeting, it waits. If the message is a scam, waiting is the dangerous part.

চিঠি (Chithi) means "letter" in Bengali. It does one thing. You point the phone at any piece of paper or any screenshot, and it says out loud, in your language:

What it is. "This is your CESC electricity bill."
What you need to do. "Pay ₹1,182.00 by 12-10-2026."
Whether it's a trap. A red প্রতারণা! (scam!) stamp, the words "Do nothing. Don't tap the link, don't call the number in the message, don't share an OTP," and one big button that calls me.

It started as a Bengali app for my family. Then I realised the same problem exists in every Indian language, so it now speaks all 22 languages in India's Eighth Schedule, plus English.

Demo

Try it: chithi-teal.vercel.app. Pick a language, then tap one of the sample photos (a scam SMS, a bill, a medicine strip), or upload your own.

Pick a language	Bengali home	A scam	A bill

The public demo runs Gemma in the cloud so you can try it without installing anything, and the page says so. At home it runs on our own laptop. More on why that difference matters below.

Code

codeswithroh / chithi

Point your phone at any bill, letter or WhatsApp forward. Hear it in your language. Know if it's a scam. Open-weight Gemma, 22 Indian languages.

চিঠি (Chithi)

Live demo: https://chithi-teal.vercel.app. Pick a language, then tap a sample photo Built for the DEV Hacktoberfest Weekend Challenge: Build for a Friend. MIT licensed.

A pocket reader for my mom and grandparents, who read Bengali but not English.

Point the phone at any bill, bank letter, medicine strip, or WhatsApp forward. Chithi reads it with Gemma (an open-weight model running on the family laptop), then says out loud, in your language:

what it is,
what you need to do (amount, due date),
whether it's a scam, with one big button to call me.

Photos never leave the house. There's no cloud API, no account, and no monthly bill.

How it works

phone (PWA, camera)  ──Wi-Fi──▶  laptop: Bun server  ──▶  Ollama + Gemma (vision)
        ▲                                │
        └── speech in your language      └── scam rule layer (can only raise risk, never lower it)
            (phone's offline voice)

server.ts serves…

View on GitHub

It's small on purpose: one Bun server, a phone web app with no framework, and under 200 lines of shared logic for the prompt, cleanup and scam rules.

How I Built It

Ma's phone (web app, camera)  ── home Wi-Fi ──▶  family laptop: Bun server ──▶ Ollama + Gemma 3 4B (vision)
       ▲                                               │
       └── spoken answer (phone's own offline voice)    └── scam rules (can raise the risk, never lower it)

The model. Gemma 3 4B, an open-weight vision model, running in Ollama on my 8 GB M3 MacBook. The phone sends a photo over home Wi-Fi. Gemma reads it and answers in a fixed JSON shape: original text, document type, a two-line explanation, what to do, amount, deadline, and a risk level of safe, caution or scam. Ollama's JSON-schema mode means the reply always parses.

The voice. The phone's own text-to-speech in bn-IN (or hi-IN, ta-IN, …). It works offline. Languages without a phone voice fall back to one that reads the same script, so Maithili goes through the Hindi voice and Konkani through Marathi.

The phone app. A tiny web app you add to the home screen. Giant buttons, big type, and nothing to learn. It has one button that opens the camera and one that picks a screenshot.

What testing taught me

Most of the work was not "call the model." It was finding the ways a 4B model fails, then making sure those failures can't reach my mom.

1. The model caught the scam, then gave the scammer's number. My first test was a fake SBI "KYC update" SMS. Gemma correctly said scam, then advised: "call the helpline number in the message to find out more." That helpline is the scammer. Since then, when the verdict is scam, the advice is fixed text written by a person in each language. The model never writes it.

2. A small model shouldn't be the only guard. A deterministic rule layer in scam.ts checks the transcribed text for OTP and PIN requests, KYC, "account blocked", lottery and prize wording, short links, .apk files, and remote-access apps like AnyDesk. It can raise the risk level and never lower it. A printed MRP on a medicine strip is recorded, not escalated.

3. Numbers are too important to paraphrase. Gemma once read ₹1,182 aloud as "one thousand one hundred eighty-eight". Now the explanation is forbidden from containing numbers at all. The amount and due date come from separate fields copied exactly as printed, and the app shows them in their own boxes.

4. Small models drift between scripts. Bengali answers picked up Korean characters. Malayalam answers picked up Romanian and Russian words. Now any letter that isn't in the reader's own script (or plain English, for brand names like SBI) is stripped, and a badly drifted answer gets one retry. Without the stripping, the phone's Bengali voice would stumble over Hangul mid-sentence.

5. An 8 GB laptop has rules. The first photo took almost four minutes while the model loaded. Then one of my fixes made things worse: the warm-up request and the real one used different context sizes, so Ollama loaded the model twice and timed out. Now the server warms the model at startup with the same settings and keeps it loaded. A photo takes 25 to 60 seconds at home, which is slow for an app and fine for a letter.

All 22 languages

On first launch, Chithi shows every language in its own script, with the phone's language suggested first. After that, everything follows the choice: the buttons, Gemma's explanation, the scam warning, the voice, the font, and right-to-left layout for Urdu, Kashmiri and Sindhi.

I was honest with myself about quality. On the 4B laptop model, Hindi, Bengali, Marathi, Telugu, Tamil, Gujarati, Urdu and Kannada are good. Odia and Malayalam were weak, and Gemma 3 4B can't write Santali's Ol Chiki script at all. Those languages carry a "beta" label and an on-screen warning to double-check with family.

The public demo

Judges can't come to my house, so the demo runs the same code on Vercel. The only difference is where Gemma lives: Gemma 4 26B (a mixture-of-experts model with 4B active parameters) on Google's free Gemini API tier. Two things I learned:

Gemma 4 thinks before it answers, and it ran out of room. The first deploy failed because the model spent 1,497 of its 1,500 output tokens thinking and never wrote the JSON. Reading a bill aloud doesn't need deliberation, so I set thinkingLevel to minimal. Replies went from 40 to 55 seconds down to about 5 seconds.
The bigger model closes the language gap. In 63 live runs across 16 languages, every scam was caught and every amount and due date was exact. Malayalam and Odia came out clean, and Santali came back in proper Ol Chiki. Same open model family, bigger size, no beta label needed.

Why Does Open Innovation Matter?

Because the photos are my mom's bank letters and prescriptions. At home, the photo goes from her phone to a laptop in the next room and stops there. There's no account, no API key, and no company's servers. A closed API would mean sending a parent's KYC details to a third party to protect them from people who want their KYC details.

Because a gift shouldn't need a subscription. This app costs nothing to run. If a pricing page changes, or a company decides Bengali isn't a priority market, my mom's reader keeps working. Open weights mean the model on that laptop is ours.

Because I could choose the model to fit the house. An 8 GB laptop runs Gemma 3 4B. A family with a 16 GB machine can run Gemma 4 instead by changing one environment variable. When the 4B model was weak in Malayalam, the answer wasn't "wait for a vendor." It was "try a bigger open model." I did, and it fixed it.

Because the safety layer has to be mine. The scam rules, the fixed advice, and the script cleanup are code I can read and change. With an open model, I can see exactly where its answer ends and my rules begin.

Where did running it at home lose? Speed. The hosted Gemma answers in 5 seconds, the laptop in 30. For a letter you read once, I'll take 30 seconds and privacy.

Handing It Over

I gave it to Ma this weekend: the laptop stays on at home, the app sits on her phone's home screen, and my number is already behind the red call button.

She used it, and she told me it's one of the best things I've built for her, and that it will help her a lot.

She was proud of what I'm doing. Honestly, that landed harder than any test passing.

My Agent Session

I built Chithi in one weekend with an AI coding agent (Claude Code) as a pair. I made the product calls (who it's for, the scam-first flow, the "never let the model write scam advice" rule), and the agent wrote and tested most of the code with me. The testing loop above, with its real failures, came out of that session.

Prize Categories

Best Use of Gemma. Gemma 3 4B runs locally on the family laptop through Ollama, and Gemma 4 26B powers the public demo through the Gemini API. The app picks the best available Gemma automatically.

Built for my mom and my grandparents. If your parents get "Dear Customer" messages too, the code is MIT-licensed. Point it at your family's laptop.

What If the Blockchain Could Judge Your Bluff Without Seeing Your Dice?

Rohit Purkait — Wed, 19 Aug 2026 09:07:15 +0000

Liar’s Dice sounds like a perfect game to put onchain.

The rules are simple, every move can be verified, and you don’t need a centralized game server deciding who won.

There is just one problem.

Blockchains are public. Liar’s Dice only works if your dice are private.

If I simply stored every roll inside a normal smart contract, anyone could inspect the state and know exactly what everyone was holding.

At that point, there is no bluffing.

You would basically be playing poker with everyone's cards face up.

So I built FHE Liar’s Dice, a decentralized version of the game where your dice remain encrypted while the game is being played.

Not hidden behind a backend.

Not stored privately in some database.

Encrypted onchain.

And the interesting part is that the smart contract can still use those encrypted dice to determine whether you are lying.

The problem with putting hidden-information games onchain

Most blockchain games actually benefit from transparency.

If you're building something like chess, every player is supposed to know the complete state of the board.

Liar’s Dice is different.

Each player starts with five dice that only they should be able to see.

Players then make public claims about the combined dice across the entire table.

You might say:

There are six 4s on the table.

The next player has two choices.

Raise the bid.

Or call your bluff.

The entire game comes from the fact that nobody knows exactly what everyone else is holding.

But a traditional smart contract has the opposite property.

Its state is transparent.

Even if the frontend refuses to display your dice, someone can simply inspect the contract, query the state, watch events, or build their own interface.

Hiding something in the UI isn't privacy.

I needed the actual game state itself to remain secret.

FHE turned out to be a very good fit for the game

I built the game using Fhenix CoFHE.

Fully Homomorphic Encryption is interesting because it allows computation to happen directly over encrypted values.

Normally encryption gives you privacy while data is stored, but you need to decrypt the data before doing anything useful with it.

With FHE, you can keep the value encrypted and still perform computations over it.

That completely changes what an onchain game can do.

In FHE Liar’s Dice, the contract generates each player's dice as encrypted values.

Conceptually, instead of the contract storing:

[2, 6, 4, 1, 3]

it stores encrypted representations of those values.

No plaintext die value is written into contract storage or emitted through an event while the round is active.

Only the player who owns that hand can unseal it and see what they rolled.

So your opponents can't read your dice.

An indexer can't read your dice.

And even the application operator doesn't get the plaintext values.

That gives the game something I couldn't get from a normal smart contract:

private state with public execution.

The weird part: checking a bluff without revealing the dice

This was the part I found most interesting while building the game.

Imagine I bid:

Six 4s.

Someone calls me a liar.

Now the contract needs to inspect every active player's dice and determine how many 4s actually exist.

In the version of Liar’s Dice I implemented, ones are wild, so they also count toward most bids.

The obvious implementation would be:

decrypt all dice
count the matches
compare count >= bid

But that defeats the entire point.

Instead, the contract performs the comparison over the encrypted values themselves.

It checks every encrypted die, calculates whether it matches the bid, includes wild ones where appropriate, and builds the result without revealing the underlying hands.

The final thing that needs to become public is essentially one bit of information:

Was the bid valid?

Yes or no.

If the true encrypted count meets the bid, the challenger loses.

If it doesn't, the bidder was lying and gets eliminated.

The actual count doesn't need to be revealed to reach that verdict.

That distinction is small, but it is the entire architecture of the game.

The chain gets enough information to enforce the rules without learning information it doesn't need.

What stays private and what stays public

I didn't want to make everything private.

That would remove one of the reasons to build the game onchain in the first place.

So I separated the game state into two categories.

Things like these are public:

who joined the table
turn order
every bid
who challenged
whether the bid was valid
who was eliminated
the final result

The active dice are private.

That creates a nice split.

The strategy stays private. The execution stays verifiable.

After a challenge resolves, the hands from that round can be revealed so everyone at the table can see what actually happened.

Then the surviving players receive fresh encrypted hands for the next round.

The last player standing wins.

Why I didn't just use a server

The easy version of this project would have been straightforward.

Generate the dice on a backend.

Send each player their own hand.

Have the server determine whether every challenge succeeds.

From a game-development perspective, that works perfectly fine.

But then the server becomes the dealer, referee, and source of truth.

It knows everybody's dice.

It could theoretically alter rolls.

It could leak information.

And players ultimately have to trust whoever operates it.

That isn't particularly interesting to me.

The point of the experiment was to see whether we could remove that trusted game master without destroying the hidden-information mechanics that make Liar’s Dice fun.

FHE makes that possible.

The smart contract becomes the referee without becoming the omniscient dealer.

I also built a completely offline practice mode

One problem with building blockchain games is that people often need to connect a wallet before they even understand what the product does.

I didn't want that.

So FHE Liar’s Dice also has a practice mode.

It uses the same basic bluffing loop but runs locally against bots.

No wallet.

No blockchain transaction.

No encryption.

You can understand the game first, then enter the actual onchain lobby when you want to play the privacy-preserving version against other people.

The distinction is intentional.

There is no reason to pretend the offline version is decentralized.

It exists purely as an onboarding layer.

The game is still intentionally simple

The current version is a prototype.

There are no wagers.

No ranked mode.

No tournament system.

No timers.

I wanted to solve the harder primitive first:

Can you run an actual hidden-information bluffing game through a smart contract without exposing the hidden information?

Once that loop works, everything else becomes product design.

One known tradeoff in the current implementation is dice generation.

The dice are derived using an encrypted random uint8, reduced modulo six and shifted into the 1–6 range.

Because 256 isn't perfectly divisible by six, there is a very small distribution bias: faces 1 through 4 appear marginally more often than 5 and 6.

For a casual prototype I accepted that tradeoff and documented it rather than hiding it.

The contracts are also unaudited, so this is absolutely not something I would attach real-money wagering to in its current form.

What building this changed for me

Before this project, it was easy for me to think about blockchain privacy mostly in terms of private transfers or private financial positions.

Building a game made the idea much more tangible.

There is a huge class of applications where you don't necessarily need to hide the entire system.

You need to hide specific pieces of state while still allowing programs to compute over them.

Games are one example.

Auctions are another.

Voting, identity, trading strategies and many financial applications have variations of the same problem.

Public blockchains are extremely good at proving that computation happened according to known rules.

FHE adds another interesting possibility:

proving that rules were followed without forcing every input involved in those rules to become public.

Liar’s Dice happens to make that idea very easy to see.

You have five dice.

Nobody else should know them.

The contract still needs to know whether your bluff worked.

And somehow both things need to be true at the same time.

That is what I wanted to build.

Try bluffing against the blockchain

The project is live here:

https://fhe-liars-dice.vercel.app/

You can jump into practice mode without a wallet or create an onchain table and play the FHE version with other players.

The simplest description of the project is still probably the one I started with:

Nobody sees your dice.

Everyone sees your lies.

I built TraceGate because my AI agent demo passed, but the traces told a different story

Rohit Purkait — Sun, 26 Jul 2026 12:46:53 +0000

Most AI agent demos stop at the final answer.

Mine did too at first. I had a support agent that could answer a refund question, call a policy tool, and avoid a prompt-injection path. From the outside, it looked fine.

Then I asked a less comfortable question: if this agent broke in production, would I actually know what happened?

That question became TraceGate.

TraceGate is a release gate for AI agents built with OpenTelemetry and SigNoz. It runs agent scenarios, sends telemetry to SigNoz, then checks whether the run produced enough evidence to safely ship.

The problem

AI agents can pass a demo while still being hard to debug.

A tool can retry three times and still return a successful answer. An LLM call can happen without cost metadata. A prompt-injection test can pass, but leave no trace of which safety path was used. Those are not product failures in the usual sense. They are observability failures.

That is what I wanted TraceGate to catch.

The idea is simple: before an agent ships, it should satisfy an observability contract. If the contract fails, the release is blocked.

What TraceGate checks

TraceGate uses a YAML contract to describe what a safe release run should include.

Here is part of the contract I used:

name: TraceGate AI Agent Release Contract
serviceName: tracegate-demo-agent

budgets:
  maxRunCostUsd: 0.005
  maxP95LatencyMs: 2000
  maxToolRetries: 1

checks:
  - id: span-agent-run
    type: required-span
    spanName: agent.run
    severity: critical

  - id: span-llm-call
    type: required-span
    spanName: llm.call
    severity: critical

  - id: attr-llm-model
    type: required-attribute
    spanName: llm.call
    attribute: gen_ai.request.model
    severity: critical

  - id: retry-budget-trace-lookup
    type: max-tool-retries
    toolName: trace.lookup
    maxRetries: 1
    severity: critical

The default demo intentionally fails one check. The trace.lookup tool retries three times, but the contract only allows one retry.

That makes the demo useful because TraceGate is not pretending everything is healthy. It blocks the release and explains why.

TraceGate FAIL
Checks: 7/8 passed
Critical failures: 1
FAIL retry-budget-trace-lookup - Worst retry count for 'trace.lookup' was 3; limit 1.

The architecture

The stack is:

Vite
React
TypeScript
Node.js
OpenTelemetry
SigNoz
OpenAI
YAML contracts

The flow looks like this:

Scenario -> Agent runner -> OpenTelemetry -> SigNoz -> TraceGate contract evaluator -> Pass or block

The Node runner executes the scenario. OpenTelemetry records spans, metrics, and logs. SigNoz receives the telemetry through OTLP. TraceGate reads the run result and evaluates it against the contract.

For the OpenTelemetry setup, I used the OTLP HTTP exporters:

const endpoint =
  process.env.OTEL_EXPORTER_OTLP_ENDPOINT ?? "http://localhost:4318";

const sdk = new NodeSDK({
  traceExporter: new OTLPTraceExporter({
    url: `${endpoint}/v1/traces`
  }),
  logRecordProcessor: new BatchLogRecordProcessor(
    new OTLPLogExporter({
      url: `${endpoint}/v1/logs`
    })
  ),
  metricReader: new PeriodicExportingMetricReader({
    exporter: new OTLPMetricExporter({
      url: `${endpoint}/v1/metrics`
    }),
    exportIntervalMillis: 1000
  })
});

In my local setup, SigNoz received spans for:

agent.run
llm.call
tool.ticket.lookup
tool.policy.search
tool.trace.lookup

A build issue I hit

The part that took the most debugging was the local SigNoz setup.

I used Foundry to run SigNoz locally. The first time I started everything, the UI was up, but the telemetry path was not useful. The collector looked alive, but the pipeline was effectively not sending the data I expected.

The issue was in the generated local configuration around the OpAMP and MCP service wiring. I patched the generated setup so the ingester pointed to the actual SigNoz service and the MCP server pointed to the SigNoz UI service. After that, the OTLP export worked and I could verify spans in ClickHouse.

That was the most “real” part of the project for me. The code for the gate was straightforward compared to proving that telemetry actually reached the backend.

The workbench

TraceGate has a landing page and a workbench.

The landing page explains the idea: ship agents only when the traces agree.

The workbench shows:

latest release verdict
checks passed
critical failures
cost
latency
gate matrix
failed evidence
SigNoz investigation query

The gate matrix is the part I care about most. It turns vague release confidence into specific checks.

For example:

Root agent run span: pass
LLM calls traced: pass
Model attribute present: pass
Cost attribute present: pass
Cost budget: pass
Trace lookup retry budget: fail
Refund support scenario: pass
Prompt injection scenario: pass

That gives a reviewer a much better starting point than “the demo worked on my machine.”

Judge test mode

I also added a judge-operated test mode because I did not want the hosted app to feel like a static mockup.

A judge can enter:

service name
scenario
tool name
retry budget
observed retries
cost
latency

Then TraceGate generates a new verdict.

For example:

service: checkout-agent
tool: inventory.lookup
allowed retries: 1
observed retries: 3

That blocks the release.

If the observed retries are changed to 0, the release becomes ready.

This makes the product easier to test without asking someone to set up my whole local environment first.

What I learned

The main thing I learned is that observability is more useful when it is tied to a decision.

Before this project, I mostly treated observability as something I would open after a bug. With AI agents, that feels too late. If an agent takes a risky path, skips metadata, hides cost, or retries a flaky tool several times, I want to know during release validation.

The second thing I learned is that “the agent worked” is too broad. I now split it into two questions:

Did the agent produce the expected outcome?
Did the agent produce enough evidence to debug that outcome?

TraceGate focuses on the second question.

What I would build next

The next version should have a visual contract editor. Writing YAML is fine for a hackathon, but a team should be able to create a release gate by choosing required spans, attributes, budgets, and scenarios in the UI.

I would also add GitHub Actions support. The natural place for TraceGate is in CI, where it can block an agent release before merge.

The final improvement would be deeper SigNoz artifacts. Each contract should generate a matching dashboard, alert, and investigation prompt so the release gate and the debugging workflow stay connected.

Final thought

TraceGate started from one uncomfortable question: if my AI agent fails later, will I have the evidence to understand it?

SigNoz already gives teams a strong place to inspect telemetry. TraceGate adds a release workflow on top of that telemetry.

The project is small, but the idea feels useful: agents should not ship only because the final answer looked good. They should ship when their behavior is traceable enough to trust.

Every AI-built site looks the same, so I built a skill that locks taste before any code is written

Rohit Purkait — Sat, 18 Jul 2026 00:40:32 +0000

I build a lot of side projects with AI coding tools. Mostly Claude Code. A few months ago I noticed something that kept bugging me. Every site I shipped looked the same. Same indigo gradient. Same default font. Same rounded cards with the same soft shadow.

Then I started noticing it on other people's projects too. Demo days, launch posts, screenshots on social media. The indigo gradient is everywhere. It is basically a uniform at this point.

This is not really the AI's fault. When you do not give a model a design direction, it picks the average of the internet. And the average of the internet is a Tailwind starter template with an indigo gradient and Inter. The model is doing exactly what it was trained to do. The problem is that nobody told it what you actually want.

So I built tastemaker. It is a skill for Claude Code, and it also works with Cursor, Windsurf, and Codex. The idea is simple: lock the design system before the AI writes a single line of UI.

Full disclosure before we go further: I built this. I am a solo builder. It is free and open source under the MIT license. I am posting it here because I want honest feedback, not because I have anything to sell you. There is nothing to buy.

Taste first, code second

A skill is just a folder of instructions the AI reads before it starts working. tastemaker forces a design decision step at the beginning, with real constraints, instead of letting the model improvise the look as it goes.

When you start a UI project with it installed, this is what gets locked before any code exists:

A palette. 5 presets, each matched to a mood. Not random hex codes. Combinations that were picked to work together.
Fonts. 24 curated Google Font pairings. A display font and a body font that actually belong on the same page.
Real assets. Illustrator-grade illustrations, recolored to your palette. No gray placeholder boxes. No generic stock photo energy.
A logo. A constructed geometric mark, plus a full favicon set, so the tab icon is not the framework default.
Motion. GSAP and ScrollTrigger wired in by default, so scroll animation is a starting point, not a TODO you never get to.

The point is not that my taste is better than yours. The point is that any taste, written down and locked, beats no taste at all.

The part where I failed

This is my favorite part of the story, mostly because it is embarrassing.

I picked the 5 palette presets by eye. They looked good to me. I was confident. Then, because I wanted to be thorough, I wrote a small Python script to check every text-on-background combination against WCAG contrast ratios.

The first run failed 2 of my 5 presets.

My eyes said the palettes were fine. The math said real people would struggle to read the text. The math was right. I went back, adjusted the failing colors, and kept running the check until everything passed. All 5 presets that ship today pass that contrast check.

That little story is the whole argument for the project. Taste feels subjective until you write it down and test it. Once it is written down, you can check it, fix it, and reuse it. My eyeballs were wrong 40 percent of the time. A short Python script was right every time.

Install

One command, then restart Claude Code:

git clone https://github.com/codeswithroh/tastemaker ~/.claude/skills/tastemaker

That is the whole setup. No API keys. No config file. No account. Restart, start a UI project, and the design system gets locked before the AI starts guessing.

More details on the site:

tastemaker-skill.online

Source code:

codeswithroh
/
tastemaker

A Claude Code skill that grounds AI-generated UI in real reference images and a persistent per-developer taste profile, instead of generic AI-slop defaults.

A skill that gives AI real design taste, so the UI it builds does not look AI-generated.

Quick start · Why · Features · Presets · How it works · Contributing

See it live and try the demo →

What this is

Tastemaker is a skill for coding agents (Claude Code, Cursor, Windsurf). You install it once and forget it. Whenever you ask your agent to build or style a UI, tastemaker steps in and gives it a real design system to work from, instead of the generic defaults every model reaches for.

It is plain Markdown and small Python scripts. Everything runs on your machine. There is no hosted backend, no account, and no API key.

Why AI UI all looks the same

Ask any model to build a UI and you tend to get the same thing: an indigo to purple gradient, a soft shadow card, a generic…

View on GitHub

What I learned

A few things, in order of how much they surprised me.

First, constraints make AI output better, not worse. I expected locking the palette and fonts to feel limiting. It did the opposite. The model stopped spending effort on design indecision and spent it on the actual product. The output got more interesting, not less.

Second, the default look is a choice. Every time you skip the design conversation, you are choosing the average of the training data. That is still a design decision. It is just a boring one you made by accident.

Third, scripts beat eyeballs. I trust my taste. My taste failed 2 out of 5 times on a basic readability check. Now I write the check first and pick the colors second, and I think that order matters more than people realize.

Fourth, design debt starts at line one. Most of us treat design as a cleanup pass at the end of a project. With AI tools, the end never arrives, because there is always one more feature to generate. Deciding first is cheaper than fixing later.

If you try tastemaker, tell me what broke. Feedback is genuinely welcome, in the comments here or as an issue on GitHub. And if it saves you a few hours, a star on the repo helps other people find it.

Understanding Flow’s Lending Protocol Architecture

Rohit Purkait — Fri, 12 Dec 2025 08:14:06 +0000

A Beginner Friendly Guide for Web3 Developers

Lending protocols are one of the most important building blocks in decentralized finance. They let users borrow, lend, and build leveraged positions without intermediaries. Protocols like Aave and Compound defined the standard for collateralized on chain lending. Flow introduces a new approach through its Flow Credit Market (FCM) and the product built on top of it, Flow Yield Vaults (FYV).

This guide explains the context behind Flow’s design, how traditional lending protocols work, and what Flow is doing differently.

1. What Is a Lending Protocol?

A lending protocol is a smart contract system where:

Users deposit assets as collateral
They borrow other assets against that collateral
A health factor keeps the position safe
Collateral is liquidated if health becomes too low

Liquidation ensures the protocol does not end up with bad debt. But liquidation risk is one of the biggest user pain points in existing systems.

2. How Existing Protocols Handle Liquidations

Example: Aave

A typical liquidation flow looks like this:

Your collateral value falls
A Keeper detects your unhealthy position
The Keeper repays some of your debt using a flashloan
The Keeper receives a large chunk of your collateral at a discount

Problems with this approach:

Liquidations are large
Keepers profit from user loss
Liquidations can happen during brief volatility
Positions can get wiped out instantly

This model works, but it is harsh and inefficient for users.

3. Flow’s Architecture: Two Layers Working Together

Flow has two related but distinct systems.

3.1 Flow Credit Market (FCM)

This is the base lending layer. It provides:

Borrowing and collateral management
Health factor logic
Liquidation rules
An automation framework for top ups and draw downs

FCM is similar to Aave in role, but with improvements in liquidation mechanics.

3.2 Flow Yield Vaults (FYV)

This is a strategy built on top of FCM. FYV uses the automation hooks inside FCM to:

Continuously monitor position health
Sell a small portion of yield tokens when collateral drops
Buy more yield tokens when collateral rises
Maintain a stable health band so liquidation never occurs

FYV behaves like an automated rebalancing engine that runs continuously.

4. How Flow Handles Liquidations Differently

Flow’s liquidation system improves upon legacy designs.

Minimal Liquidation

Flow sells only the smallest amount of collateral needed to restore health.

DEX First Execution

Liquidations are routed through a decentralized exchange:

Predictable pricing
No dependency on external bots
Best possible market rate

If a Keeper wants to liquidate, they must beat the DEX price.

Multiple Small Adjustments

If the market keeps dropping, FCM performs several small corrections instead of one destructive liquidation.

5. Why FYV’s Automation Matters

Flow Yield Vaults automate everything a user would manually do.

Example behavior:

If FLOW price drops ten percent, FYV sells ten percent of yield tokens
If FLOW price rises fifteen percent, FYV buys fifteen percent more

This keeps users:

Maximally invested when safe
Hedged when risky
Protected from liquidation

Simulations show FYV achieves higher returns than similar strategies on Aave because:

It avoids liquidation loss
It maintains safe leverage
Automation captures more upside opportunities

6. Key Takeaways for Developers

Lending protocols can be redesigned to be more user friendly

Flow reduces liquidation pain and aligns incentives between the protocol and users.

Automation is becoming essential

Instead of relying on keepers or manual adjustments, Flow builds automated risk management at the protocol layer.

Deterministic liquidation improves user trust

DEX based execution ensures transparent and predictable behavior.

7. Summary

Traditional Lending Protocols

Large liquidations
Keeper profit is user loss
Sudden position wipeouts
No built in protection

Flow Credit Market + Flow Yield Vaults

Automated health balancing
Minimal liquidation
DEX driven execution
Continuous rebalance strategy
Higher return with reduced risk

Flow builds a safer and more efficient foundation for leveraged yield strategies, especially for developers building products on top of lending primitives.

Adding Telegram Notifications to Your Application: A Step-by-Step Guide

Rohit Purkait — Tue, 07 Jan 2025 13:30:49 +0000

Telegram is a powerful and widely-used messaging platform that offers seamless integration with applications through its Bot API. Whether you’re building a monitoring service, a trading bot, or a notification system, Telegram notifications can enhance user engagement by providing instant updates.

In this blog, we’ll walk you through the process of setting up a Telegram bot and enabling it to send notifications to your desired chat.

Why Telegram for Notifications?

• Ease of Use: Telegram bots are easy to set up and integrate with your application.

• Instant Delivery: Notifications are delivered in real-time.

• Global Reach: Telegram has millions of users worldwide.

• Customizable Experience: You can tailor the bot to send messages in any format, including text, images, and even buttons.

Step 1: Create a Telegram Bot

The first step is to create a bot in Telegram using the BotFather:

Open Telegram: Log into your Telegram account.
Search for BotFather: In the search bar, type “BotFather” and select the verified bot.
Start a Chat: Send the /start command to begin interacting with BotFather.
Create a New Bot: Use the /newbot command. You’ll be prompted to:
• Choose a name: This is the display name for your bot.
• Create a username: Must end with “bot” (e.g., MyNotificationBot).
Receive Your Bot Token: Once created, BotFather will provide a token that you’ll use to authenticate API calls. Save this token securely, as it’s your bot’s access key.

Step 2: Get Your Chat ID

Telegram needs to know which chat to send notifications to. To retrieve your chat ID:
1. Start a Chat with Your Bot: Search for your bot’s username in Telegram and send a message (e.g., “Hello”).
2. Use the Bot API: Use the following API endpoint to fetch updates and find your chat ID:

https://api.telegram.org/bot/getUpdates

Replace with the token provided by BotFather.

3.  Inspect the Response: The response will include a JSON object. Look for the chat field, which contains the id. This is your chat ID.

Step 3: Understanding the Telegram Bot API

Telegram provides a simple HTTP-based API to interact with your bot. The endpoint to send a message is:

https://api.telegram.org/bot/sendMessage

Required Parameters
• chat_id: The ID of the chat where the message should be sent.
• text: The message content.

Optional Parameters
• parse_mode: Format text using Markdown or HTML.
• disable_notification: Send messages silently (without sound).
• reply_markup: Add interactive buttons or keyboards.

Step 4: Test Your Telegram Bot

Once you have the bot token and chat ID, it’s time to test. You can use a tool like curl or Postman to send a sample message:

Using curl

curl -X POST "https://api.telegram.org/bot/sendMessage" \
-H "Content-Type: application/json" \
-d '{"chat_id": "", "text": "Hello from my bot!"}'

Using Postman
1. Set the method to POST.
2. Use the URL: https://api.telegram.org/bot/sendMessage.
3. In the body, use the JSON format:

{
"chat_id": "",
"text": "Hello from my bot!"
}

Step 5: Automating Notifications

To integrate Telegram notifications into your application, you’ll need to:
1. Capture the event or payload in your app that triggers a notification.
2. Format the message content dynamically (e.g., using placeholders for data like symbols, signals, or confidence levels).
3. Use the Telegram Bot API to send the message programmatically.

Best Practices
• Secure Your Bot Token: Treat it like a password. Avoid hardcoding it in your application.
• Rate Limiting: Telegram has limits on API requests. Ensure your app respects these limits to avoid being blocked.
• Error Handling: Check the API response for errors and retry failed requests if necessary.
• Use Webhooks: For advanced integrations, consider setting up a webhook to receive real-time updates from Telegram.

Conclusion

Adding Telegram notifications to your application is a straightforward way to enhance communication with your users. By leveraging the Telegram Bot API, you can deliver real-time updates, alerts, or even automate workflows with minimal effort.

This blog covered the setup process up to testing your bot. In the next part, we’ll dive into programmatically sending notifications using a backend service. Stay tuned!

If you have any questions or need assistance, feel free to drop them in the comments below. Happy coding! 🚀

Compiling 2025: My Roadmap for the Year Ahead

Rohit Purkait — Thu, 02 Jan 2025 21:56:10 +0000

This is a submission for the 2025 New Year Writing challenge: Compiling 2025.

As we step into 2025, I’m excited to share my personal roadmap for the year—a mix of new skills, ambitious projects, and career aspirations. It’s all about diving deeper into Web3, building tools to empower developers, and evolving my professional journey.

New Skill: Embracing Web3

The buzz around Web3 continues to grow, and I believe 2025 will be its breakout year. To prepare, I’m delving headfirst into this transformative technology. My learning path includes mastering Solidity, exploring Move by Aptos, and diving into other Web3 tools and frameworks.

Web3 represents the future of decentralized applications, and I’m thrilled to align my skillset with this rapidly evolving space. The potential is limitless, and I can’t wait to see where this journey leads.

Side Projects: Building for the Community

Sepolia Faucet

One of my key projects is creating a Sepolia faucet where developers can purchase Sepolia tokens using INR. Currently, most faucets require 0.001 ETH on the mainnet—a barrier for newcomers just starting out.

By offering a more accessible solution, my goal is to fuel creativity and innovation. Developers will be able to acquire Sepolia ETH with a minimal amount of INR, allowing them to focus on building and experimenting with their dApps. This project isn’t just about simplifying access—it’s about empowering the next wave of Web3 creators.

Just a base sneak peek. Will be launching on 7th Jan, 2025.

Decentralized Identification (DeID)

Another project close to my heart is building dApps around Decentralized Identification (DeID). Our current identification systems are outdated and ill-equipped for the modern era, where data breaches are increasingly common.

Through DeID, I envision a system that allows individuals to securely verify their identity wherever they go, putting control back into the hands of the user. This project is a step toward a future where personal data is safe, accessible, and decentralized—a future I’m eager to help shape.

Career Aspirations: Shifting Focus to Smart Contracts

As a Full Stack Developer, I’ve had the opportunity to work across the technology spectrum, but this year, I’m pivoting toward a specialized path: Smart Contract Development.

My goal is to deepen my understanding of this crucial Web3 component and eventually transition into a dedicated role as a smart contract developer. This shift aligns perfectly with my passion for blockchain technology and the ever-expanding possibilities of decentralized solutions.

Looking Ahead

2025 is shaping up to be a pivotal year for me, full of learning, building, and growing. Whether it’s mastering new skills, developing impactful projects, or pursuing career aspirations, I’m excited for what lies ahead.

To all my fellow developers, dreamers, and innovators—let’s make 2025 a year to remember!

What’s on your 2025 roadmap? Share your journey and join the conversation!

DEV Community: Rohit Purkait

TJ Holowaychuk left Express in 2014. 6,483 of his lines still run. Gemma called his commits "3,527 silent years".

What I Built

Demo

Code

codeswithroh / bhoot

भूत: ghost, and the past. The people who left your repo but whose code still runs, and the files that died, remembered by a local Gemma and checked against git.

Bhoot · भूत

Contents

How I Built It

Git gives the facts

Gemma writes the words

"3,527 silent years"

My checker was wrong too

Testing it

Family plots

Why Does Open Innovation Matter?

The Spirit of It

Prize Categories

'Baad mein' means later. Gemma reads the WhatsApp chat you keep with yourself, and tells you what you can forget

What I Built

Demo

Code

codeswithroh / baad-mein

Your WhatsApp chat with yourself, read slowly by Gemma 4 in your browser. One card in the morning: what's due, what to buy, who owes what, and what you can let go.

Baad Mein (बाद में, "later")

How I Built It

Slow and steady, on purpose

Gemma copies. Code reads.

Why code does the dates: 8 out of 19

Testing it

Two bugs worth telling

What it can't do yet

Why Does Open Innovation Matter?

The Lazy Payoff

Prize Categories

'Kal' means yesterday and tomorrow. I built home bakers a WhatsApp order sheet that never guesses which.

What I Built

Demo

Code

codeswithroh / pakka

A home baker's WhatsApp orders, turned into tomorrow's bake sheet. Gemma 4 E2B reads the chats on the phone; code checks every detail.

Pakka

How it works

How I Built It

Gemma copies. Code reads.

Kal is two days

Testing it

What it can't do yet

Why Does Open Innovation Matter?

Prize Categories

I built an AI that only works when my phone is in my pocket

What I Built

I took it outside

What a drift actually looks like

Demo

Code

codeswithroh / drift

A walk with no destination. On-device Gemma writes the rules, Kokoro reads them, your phone stays in your pocket.

Drift

Why

Features

How I Built It

The trick: the whole walk is one audio file

Things that broke (and what I learned)

Pip

Why Does Open Innovation Matter?

Prize Categories

My mom reads Bengali, not English. So I built her a reader that catches scams, on open-weight Gemma.

What I Built

Demo

Code

codeswithroh / chithi

Point your phone at any bill, letter or WhatsApp forward. Hear it in your language. Know if it's a scam. Open-weight Gemma, 22 Indian languages.

চিঠি (Chithi)

How it works

How I Built It

What testing taught me

All 22 languages

The public demo

codeswithroh
/
tastemaker