DEV Community: Anmol

Somewhere Out There, Forgotten Accounts Still Have My Name, I Went Looking: So I built Ghostbook, a Gemma-Powered Map of Your Forgotten Accounts.

Anmol — Sun, 01 Nov 2026 06:32:30 +0000

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

The story

It starts with a small moment.

You open an app you have not touched in a year. Maybe it is a food delivery app, an old shopping site, a course platform you signed up for in a burst of motivation. The screen asks for an email. You type the one you always use.

No account found with this email.

You pause. You try your other Gmail. The one you made in college. The one you made for "serious things." The one you made because you forgot the password to the first one.

No account found with this email.

Now you are not sure there is an account at all. Maybe you signed up with Facebook. Maybe you used a username instead of an email, and you have no idea what you typed that day. You sit there with the cursor blinking, and you feel something odd for such a small problem: a tiny sting of embarrassment. You are locked out of something you made yourself.

So you do what everyone does. You click Forgot password? Reset here.

And the reset email goes to an inbox you stopped checking two years ago, or it never comes, or it says "if an account exists, we have sent a link," which tells you nothing. You close the app. Whatever you came here to do, you do not do it.

I have lived this loop more times than I can count, and I started to notice something. The problem was never the password. Password managers are good at that. The problem was three questions I could no longer answer:

Which email did I use?
What was my username?
How do I get back in?

Every account you create quietly produces those three facts, and then your brain throws them away. Multiply that by a few hundred apps and websites, and you are carrying a hidden pile of lost context.

Then the theme of this challenge arrived: Ghost in the Machine. And it clicked. Every forgotten account is a ghost. It is something you made, abandoned, and lost track of. It still holds your name, your email, and maybe your address or your orders, sitting in a database you have not thought about in years. It is haunting your inbox, and you cannot even find it.

What I Built

So I built Ghostbook is a map of your online accounts, not a vault of passwords. It remembers which email you signed up with, which username you picked, and how to reset access, so the next time you forget, "Forgot password" works on the first click. Gemma, an open-weight model, turns messy notes into structured entries, answers questions about your accounts in plain language, and writes a haunting report about the forgotten accounts lurking in your life.

Built for the Hacktoberfest Open-Source AI Challenge, Week 4: Ghost in the Machine.

The problem
You signed up for hundreds of apps. For most of them you can no longer answer three questions:

Which email did I use?
What was my username?
How do I get back in?
So you click "Forgot password", guess an email, get a "no account found" message, and repeat. Every forgotten account is also a ghost: an old login that still holds your data and still sits in someone's database.

What it does

Account map. Store site, email, username, login method, reset route, last used date, and notes.
Paste to account. Paste a signup email or a rough note and Gemma extracts a structured entry for you to review and save.
Ask your graveyard. Ask "which email did I use for my bank?" and get an answer grounded in your own entries.
Haunting report. Plain-code checks find stale accounts, one email tied to too many accounts, and entries with no recovery route. Gemma then writes a short, spooky summary.
Hybrid AI. Run Gemma locally with Ollama, through a cloud API (Groq or Google AI Studio), or local-first with a cloud fallback.

How It Fits "Ghost in the Machine"

The theme asks for something spooky, or something that honors the past. Ghostbook does both, and the ghost in the title is meant literally.

1. The ghosts are real. Every account you made and forgot is a ghost in someone else's machine. It still holds your name, your email, maybe your address and order history, in a database you have not thought about in years. It is not dead, it is just unattended. That is the spooky part: your past self is still out there, keeping a little of you alive without your knowing.

2. The machine is the haunted house. Hundreds of apps and websites, each holding a piece of you, each with its own login rules. You cannot walk through them all and check. Ghostbook gives you a map of the house, so you can see where the ghosts are.

3. Gemma is how the ghosts are found. The model reads the messy traces you leave behind (a signup email, a half-remembered note) and turns them into entries. It answers "which email did I use for my bank?" from your own records. Then the haunting report scores your book from Quiet to Poltergeist and writes a short, slightly spooky summary of what to deal with first. [Keep the score band names only if they are in your final UI.]

4. It honors the past. In the spirit of Día de los Muertos, the point is remembering what you left behind instead of letting it fade unseen. The older an account's last-used date, the more its card fades in the ledger, until it becomes a dashed-border ghost. You watch your digital past dim, and then you choose what to keep, secure, or finally let go. [Keep this only if the fading cards are built.]

5. It looks ahead to the afterlife. Your accounts outlive your attention, and sometimes they outlive you. A "digital ofrenda" mode, a list of accounts a trusted person would need to find, is on the roadmap. That one is not built yet. I am saying so plainly because honoring the past should not start with overclaiming.

Gemma powers three features:

Paste to account. Paste a signup email or a messy note like "zomato, second gmail, username anmol_k", and Gemma extracts a structured entry. You review it, and nothing is saved until you say so.
Ask your graveyard. Ask "which email did I use for my bank?" and get an answer grounded only in your own entries. If the answer is not there, it says so instead of guessing.
Haunting report. Plain code finds stale accounts, one email tied to too many accounts, duplicate sites, and entries with no recovery route. Gemma then writes a short, slightly spooky summary of what to clean up first.

The interface leans into the theme quietly. The older an account's last-used date, the more its card fades, until it becomes a dashed-border ghost. You can literally watch your digital past dim. [Keep this paragraph only if the fading cards are built in your final version.]

Demo

will uplaod soon

Code

AnmolCanCodes / Ghostbook

Ghostbook

Find the ghosts haunting your inbox.

Ghostbook is a map of your online accounts, not a vault of passwords. It remembers which email you signed up with, which username you picked, and how to reset access, so the next time you forget, "Forgot password" works on the first click. Gemma, an open-weight model, turns messy notes into structured entries, answers questions about your accounts in plain language, and writes a haunting report about the forgotten accounts lurking in your life.

Built for the Hacktoberfest Open-Source AI Challenge, Week 4: Ghost in the Machine.

The problem

You signed up for hundreds of apps. For most of them you can no longer answer three questions:

Which email did I use?
What was my username?
How do I get back in?

So you click "Forgot password", guess an email, get a "no account found" message, and repeat. Every forgotten account is…

View on GitHub

How I Built It

Stack: React and Vite on the frontend, FastAPI and SQLAlchemy on the backend, SQLite for storage, and Gemma as the model.

                  +----------------------------+
                  |   React + Vite frontend    |
                  |  list / add / ask / report |
                  +-------------+--------------+
                                | /api  (Bearer session token, held in memory only)
                  +-------------v--------------+
                  |        FastAPI backend     |
                  |                            |
                  |  routers: auth, accounts,  |
                  |           ai, haunting     |
                  |                            |
                  |  security.py  scrypt + Fernet
                  |  redaction.py strip secrets before any cloud call
                  |  llm.py       provider-agnostic client
                  +------+---------------+-----+
                         |               |
              +----------v---+     +-----v------------------------+
              |   SQLite     |     |  LLM provider (by LLM_MODE)  |
              | encrypted    |     |  local : Ollama              |
              | fields only  |     |  cloud : Groq / Google AI    |
              +--------------+     |  hybrid: local, then cloud   |
                                   +------------------------------+

One client, any Gemma

LLM_MODE=local | cloud | hybrid | off

This design came from a real constraint. My laptop cannot run Gemma locally. If I had hard-wired one hosted API, that would have been the end of any privacy story. Because the client is provider-agnostic, I built against hosted Gemma while the exact same code runs against a local model on better hardware.

Being honest about what leaves your machine

That constraint made me think hard about one question: in cloud mode, what actually gets sent? I did not want to hand-wave it, so each feature sends the minimum it needs:

Feature	Sent to the cloud provider
Paste to account	The pasted text, after passwords, OTPs, card numbers and ID-style numbers are masked
Ask your graveyard	Your question plus a few candidate entries picked by a local keyword filter (site, email, username, login method). Notes stay local by default
Haunting report	Aggregate counts only, like "14 stale accounts". No account details

In hybrid mode, the messages are rebuilt for each provider attempt. If a request falls back from local to cloud, the redaction and minimization are applied at that moment, instead of reusing a payload that was built for the local model.

Security design

A master passphrase is set on first run and never stored.
scrypt turns it into a key, and every account field is encrypted with Fernet. The database holds ciphertext only.
The key lives in server memory for the session and is dropped when the vault locks. Sessions expire after idle time, and repeated wrong passphrases trigger a lockout.
The frontend keeps its token in memory, not in localStorage. Refreshing the page means unlocking again, by design.
The UI always shows an AI badge (AI: local, AI: cloud, and so on), so you can see where your data goes instead of trusting a settings page.

Things that were harder than they looked

Getting reliable structured output from Gemma. I could not rely on JSON mode being supported everywhere, so the prompts put all instructions in a single user message, the parser strips code fences and extracts the JSON object, and it retries once with a repair instruction before giving up cleanly.
Treating pasted text as hostile. A signup email can contain anything, including instructions aimed at the model. The prompt marks pasted text as untrusted data, and the model's output is rendered as plain text only.
Never failing because the AI failed. The haunting report falls back to a deterministic template summary if the model is off or unreachable. The ledger itself works with no AI at all.

Why Does Open Innovation Matter?

Where you have accounts is one of the most personal things about you. It reveals your banks, your health apps, your late-night shopping, and the sites you would rather forget. That is exactly the kind of data I do not want locked inside one company's API.

Open weights gave me three things a closed API would not:

A privacy choice instead of a privacy policy. With a closed model, "where does my data go?" is answered by a vendor's terms. With Gemma, it is a setting. In local mode with Ollama, nothing leaves your machine and the app works with the internet off. In off mode, search still works with no AI at all. The AI badge in the UI is the app's answer to the question every user should ask.

No lock-in. Ollama, Google AI Studio, and Groq all run through the same client. If a provider changes its pricing, retires a model, or disappears, I change one line of config. A tool whose whole purpose is helping you remember things should not die the day someone else's service does.

A path from "my laptop can't" to "yours can." I built on hosted Gemma because my hardware could not run it. Someone with a stronger machine runs the identical code fully offline. A closed model offers no equivalent of that second option.

The Spirit of It

There is an idea in Día de los Muertos that people stay alive as long as someone remembers them. I think accounts work the other way around. They stay alive because nobody remembers them. Years later they are still there, quiet and forgotten, holding a little piece of who you were when you signed up.

I play games like PUBG, Valorant, and chess, but there's one frustrating thing that always catches me off guard: after taking a break or reinstalling a game, I can never remember which Gmail I used, what username I had, or whether I signed up with Google or Facebook. I've wasted time trying to recover accounts I already owned. That's where Ghostbook came from, a personal ledger that remembers the accounts I tend to forget, so the next time I return, I don't have to start guessing all over again.

Ghostbook will not bring anyone back. But it does something small and kind: it helps you remember what you left behind, and decide what to keep and what to finally let go. On my roadmap is a "digital ofrenda" mode, a list of accounts a trusted person would need to know about. Your accounts outlive your attention, and sometimes they outlive you. Someone should be able to find them.

Prize Categories

Best Use of Gemma: Gemma is the core of the project. It extracts account entries from messy text, answers questions grounded in the user's own entries, and writes the haunting report summary. It runs locally through Ollama or hosted through Google AI Studio, with the same code.
Best Use of GitHub Copilot: I leveraged GitHub Copilot to streamline architectural planning and accelerate code development. However, all core decisions regarding the product roadmap, workflow execution, feature set, and end-to-end project delivery were entirely my own.

I Had 5,000 Screenshots and Couldn’t Find Any, So I Built: SnapRecall:Type What Text You Remember, Find the Screenshot

Anmol — Mon, 26 Oct 2026 05:32:10 +0000

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

What I Built

SnapRecall is a screenshot search tool. It watches your screenshots folder, lets an AI model read every image in the background, and builds a private search index. Later, you type whatever you remember about the screenshot ("rahul payment 2500", "docker permission error", "wo flight ticket wala") and the matching screenshots show up.

How I got the idea

I take a lot of screenshots. A payment confirmation, a WhatsApp chat I might need as proof, an error message I want to Google later, a ticket, a recipe, a random detail from a group chat. I never organize them, because the whole point of a screenshot is that it takes one second.

The cost shows up later. My screenshots folder has thousands of files, all named like this:

screenshot_2026-10-24-14-55-16.png
screenshot_2026-10-24-14-55-41.png
screenshot_2026-10-24-15-02-07.png

When I need one specific image, those names tell me nothing. I end up scrolling through hundreds of nearly identical thumbnails, squinting at each one, and sometimes giving up. It is not a big problem, but it happens often, and it is exactly the kind of tedious work that a computer should do instead of me.

When I read the "slow and steady" theme, this was the first thing I thought of. It is a task that should happen quietly in the background, with no effort from me, while I do something else.

Two ideas, one choice

I had two possible solutions:

Rename on save. The moment a screenshot is taken, an AI reads it, summarizes it, and renames the file with the important words. A WhatsApp chat about rent becomes something like whatsapp_rahul_rent_payment.png.
Search by memory. Leave the files alone. When I cannot find a screenshot, I type the words I remember from inside it, and the app shows me the matches.

Renaming looked simple, but when I thought it through, it had problems. A filename is one guess about what I will remember later, and the AI's guess is often not the thing I remember. A screenshot of a chat could be filed under the contact's name, the topic, or the amount, and I might search by any of them. Renaming files can also break references in other apps or sync tools, and after a few thousand files, long auto-generated names start to look the same again.

Search works with whatever I happen to remember, and it does not touch my files. So I chose search as the core, and I treat smart renaming as a possible add-on for later (with a preview and an undo, not silent changes).

Who it is for

Anyone with a messy screenshots folder: students who screenshot notes, developers who save error messages, and people who screenshot payments, chats and tickets as proof. I also built it with Hindi and Hinglish in mind, because that is how I actually think and type. A lot of the text in my screenshots is in Hindi or mixed, and I did not want a tool that only works for clean English.

Features

Background indexing: new screenshots are picked up automatically soon after they are saved
A slow, throttled backfill of your old screenshots, so a big backlog never needs your attention
A vision model reads each screenshot and produces a short summary, tags, an app type (chat, payment, code, error, ticket...) and the text it can see
Hybrid search: keyword matching for exact names, amounts and error codes, plus semantic search for vague memories
English, Hindi and Hinglish queries
A simple React interface with a thumbnail grid, a larger preview, and live indexing progress with pause and resume

Demo

[demo]

Code

AnmolCanCodes / snaprecall

SnapRecall:Find any screenshot by typing what you remember about it..Built for the Hacktoberfest DEV Challenge, Week 3 (theme: "Slow and Steady")

SnapRecall

Find any screenshot by typing what you remember about it.

SnapRecall watches your screenshots folder, lets an AI model read every image in the background, and builds a searchable index. Instead of scrolling through thousands of files named screenshot_2026-10-24-14-55-16.png, you type "rahul payment 2500" or "docker permission error" and the matching screenshots appear.

Find any screenshot by typing what you remember about it.

AI-powered screenshot indexing · Hybrid search · English, Hindi & Hinglish

Built for the Hacktoberfest DEV Challenge, Week 3 (theme: "Slow and Steady").

View on GitHub

How I Built It

The stack

Backend: Python 3.11 and FastAPI
Frontend: React 18, TypeScript and Vite, with plain CSS and no UI framework
Storage: SQLite for everything, with FTS5 for keyword search and sqlite-vec for vector search
Folder watching: watchdog
Images: Pillow for downscaling and thumbnails
Models: a vision model that reads each screenshot and an embedding model for semantic search, either hosted (Gemini API) or local (Ollama)
Optional OCR: Tesseract, in English and Hindi

SQLite was a deliberate choice. For a personal tool, one file with no database server to install is the right amount of infrastructure, and it holds the metadata, the keyword index and the vector index in the same place.

The pipeline

 +---------------------------------------------------------------------------------------+
 |                                  INGESTION LAYER                                      |
 |                                                                                       |
 |  Screenshots Folder (SCREENSHOT_DIR)                                                  |
 |         │                                                                             |
 |         ├─► [Startup Backfill Scanner] ── (scandir walk, skips temp/ignored files) ──┐ |
 |         │                                                                            ▼ |
 |         └─► [Live Watcher (Watchdog)] ── (write stability check, move/delete sync) ─►│ |
 +--------------------------------------------------------------------------------------│+
                                                                                        │
                                                                                        ▼
 +---------------------------------------------------------------------------------------+
 |                             QUEUE & BACKGROUND WORKER                                 |
 |                                                                                       |
 |  SQLite `images` Table (status: pending ──► processing ──► done / failed)             |
 |         │                                                                             |
 |         │  • Claims newest first (ORDER BY mtime DESC, id DESC)                       |
 |         │  • Throttles between images (WORKER_THROTTLE_SECONDS)                       |
 |         │  • Daily budget tracking & auto-resume at midnight                          |
 |         │  • Exponential backoff on 429 rate limits & retry-after parsing             |
 |         ▼                                                                             |
 +---------------------------------------------------------------------------------------+
                                           │
                                           ▼
 +---------------------------------------------------------------------------------------+
 |                                 INDEXING PIPELINE                                     |
 |                                                                                       |
 |  1. Checksum & Deduplication:                                                         |
 |     Computes SHA-256. If file hash already indexed, copies vector & metadata instantly |
 |     (skips LLM & embedding calls completely — zero cost & instant!).                 |
 |                                                                                       |
 |  2. Image Preprocessing:                                                              |
 |     Reads dimensions, downscales longest side to MAX_IMAGE_SIDE (default 1024px),      |
 |     generates base64 payload.                                                         |
 |                                                                                       |
 |  3. Parallel Extraction:                                                              |
 |     ┌────────────────────────────────────┐    ┌────────────────────────────────────┐  |
 |     │ Vision Analysis (Gemini or Ollama) │    │ Optional OCR (Tesseract eng+hin)   │  |
 |     │ Structured JSON output:            │    │ Extracted verbatim text strings    │  |
 |     │ - summary (concise overview)       │    │ (enabled if OCR_ENGINE=tesseract)  │  |
 |     │ - tags (3-8 categorical tags)      │    │                                    │  |
 |     │ - app_type (chat, payment, code...)│    │                                    │  |
 |     │ - visible_text (Hindi / Hinglish / │    │                                    │  |
 |     │   English verbatim text)           │    │                                    │  |
 |     └─────────────────┬──────────────────┘    └─────────────────┬──────────────────┘  |
 |                       └─────────────────┬───────────────────────┘                     |
 |                                         ▼                                             |
 |  4. Document Text Assembly & Embeddings:                                              |
 |     Combines summary + type + tags + visible text + OCR into unified document text.   |
 |     Generates dense embedding vector (EMBEDDING_DIM = 768).                           |
 |                                                                                       |
 |  5. Storage & Triggers:                                                               |
 |     - Updates `images` table with metadata & status='done'.                           |
 |     - SQLite trigger updates `images_fts` (FTS5 BM25 index with unicode61).           |
 |     - Inserts vector into `vec_images` (sqlite-vec KNN virtual table).                |
 |     - Generates lightweight WebP thumbnail in `data/thumbnails/{id}.webp`.            |
 +---------------------------------------------------------------------------------------+
                                           ▲
                                           │
 +---------------------------------------------------------------------------------------+
 |                              HYBRID SEARCH & RETRIEVAL                                |
 |                                                                                       |
 |  User Query (Search Box) ────────────────────────────────────────────────────────┐    |
 |         │                                                                        │    |
 |         ▼                                                                        ▼    |
 |  [Keyword Search Leg]                                                   [Semantic Leg]|
 |  - Sanitizes query (safe tokens & Devanagari)               - Embeds query with task  |
 |  - BM25 matching via SQLite FTS5                            - KNN vector search via   |
 |  - Extracts highlighted snippets                              sqlite-vec              |
 |         │                                                                        │    |
 |         └───────────────────────────────┬────────────────────────────────────────┘    |
 |                                         ▼                                             |
 |                      [Reciprocal Rank Fusion (RRF_K=60)]                              |
 |                      Fuses ranks: score = Σ (1 / (60 + rank))                         |
 |                      Graceful fallback: degrades to keyword-only if provider offline  |
 |                                         │                                             |
 |                                         ▼                                             |
 |                            FastAPI REST API (/api/search)                             |
 |                                         │                                             |
 |                                         ▼                                             |
 |                   React 18 Frontend (Search, Previews, Progress Bar)                  |
 +---------------------------------------------------------------------------------------+

Finding screenshots: the watcher and the queue

On startup, a scanner walks the screenshots folder and queues anything new or changed. It skips hidden files, temporary downloads and unsupported formats, and it cleans up records for files that were deleted. After that, a live watcher takes over. When a new screenshot appears, it waits until the file size stops changing, so it never reads an image the operating system is still writing.

Every image becomes a row in SQLite with a status (pending, processing, done or failed). That table is the job queue. The worker claims the newest images first, so the screenshot you took five minutes ago becomes searchable before the ones from last year.

What the model does with each screenshot

For every image, the worker:

Computes a SHA-256 hash. If an identical image was already indexed, it copies the existing metadata and vector, and no model call happens at all.
Downscales the image so its longest side is at most 1024 px by default, which cuts bandwidth and cost.
Asks the vision model for structured output: a one or two sentence summary, 3 to 8 tags, an app type (one of 13, such as chat, payment, code, error, ticket or email), and the visible text, with names, amounts, error codes and Hindi or Hinglish preserved as written.
Optionally runs Tesseract OCR in parallel. It is off by default, because the vision model already reads the text.
Merges all of that into one document, turns it into a 768-dimension embedding, and stores everything, plus a small thumbnail.

The original file is never renamed, moved or modified.

Why the search is hybrid

There are two very different ways people look for a screenshot, and one search method cannot cover both.

When the memory is exact (a name, an amount like "2500", an error code), keyword search wins, because semantic search tends to blur exact tokens together. When the memory is vague ("the bus ticket one", "the chat where we decided the date"), keyword search fails unless the words match, while semantic search finds it by meaning.

SnapRecall runs both and merges the two ranked lists with Reciprocal Rank Fusion, where each result scores the sum of 1 / (60 + rank) across the lists it appears in. A result that ranks well in either list rises to the top, and there are no raw scores on different scales to compare. The keyword side sanitizes the query into safe tokens and handles Devanagari correctly. If the embedding service is unavailable, search falls back to keywords only instead of failing, and the response says it is degraded.

Slow and steady, on purpose

For this challenge, the theme decided how the indexer works. Reading thousands of images with a model is heavy, and a tool that tries to do it all at once either freezes your computer or burns through API limits and dies halfway. So the worker is patient by design:

It processes one image at a time, with a configurable pause in between
On an API rate limit (HTTP 429) it reads the Retry-After header and backs off, and that does not count as a failed attempt
It supports a daily request budget. When the budget or the provider's quota runs out, it pauses itself and resumes automatically at local midnight
The queue lives in SQLite, so after a restart it continues with the images that are still pending
Newest screenshots go first

You keep working, and the index quietly catches up. The backend also has a pytest suite covering the pieces that are easiest to get subtly wrong, like query sanitizing, rank fusion and the worker's behavior.

One codebase, two ways to run

The model layer sits behind a single setting, LLM_PROVIDER. The database, search, worker and interface are identical in both modes.

	Hosted (`gemini`)	Local (`ollama`)
Vision model	Gemini API (repo default: `gemini-3-flash-preview`)	Gemma, for example `gemma3:4b`
Embeddings	`gemini-embedding-001`	EmbeddingGemma
Needs internet	Yes	No, after the models are downloaded
Where screenshots go	Sent to Google's API	Never leave your machine
Hardware	Any laptop	A GPU or a fast CPU with 8 GB+ RAM
Cost	Free tier with limits, then pay per request	Electricity only

I started with a fully local plan. Then I looked at my laptop, which is old and weak, and a vision model would crawl on it. Hosted mode keeps the backend light: the app only watches a folder, writes to SQLite and serves a few endpoints, while the heavy model work happens remotely. That is the mode my demo uses.

I want to be precise about what is open. In hosted mode, the models are Google's hosted models, and they are not open-weight. The open-weight path is local mode, with Gemma and EmbeddingGemma.

Why Does Open Innovation Matter?

SnapRecall is designed around the open-weight philosophy:

Deployment freedom: The architecture works identically whether connected to hosted APIs or run entirely locally via open-weight models like Gemma.

Long-term preservation: Unlike proprietary cloud services that can deprecate models or shut down APIs, open-weight models remain functional offline indefinitely

Predictable economics: Local processing has zero marginal cost per image, enabling you to index tens of thousands of screenshots without subscription fees.

True privacy: Screenshots frequently contain OTPs, bank statements, personal chats, and proprietary code. Open-weight models empower you to keep sensitive personal data completely confidential.

Does running your own model mean it works without an internet connection?
Yes. In local mode, you pull the models once through Ollama, and the whole pipeline runs without a network connection. A closed API cannot offer that, because the model lives on someone else's server. My demo runs in hosted mode, so I am not presenting offline results here, but the switch is one setting in the same codebase.

Does it keep personal messages and files on your own machine?
This is the strongest reason open weights matter for this project. Screenshots hold OTPs, bank messages, private chats and ID photos, which is some of the most sensitive data on a device. In local mode, nothing leaves the machine: not the images, not the extracted text, not the vectors, and not the search queries. In hosted mode, downscaled screenshots and search queries are sent to the provider over HTTPS, and the README says so plainly. A closed vision API has only that second path. An open model gives the user a choice.

Does it let you set it up once and never pay for it again?
In local mode, yes. After setup, indexing tens of thousands of screenshots has no per-image cost, and re-indexing is free. That matters for a tool whose whole job is to process a huge number of images, because per-image pricing grows with every backlog and every model change. On the hosted route I used the free tier, and its limits shaped the design directly, which is why the worker is throttled, respects rate limits and has a daily budget.

Where did the open approach work better than a closed one?
I will be honest about both sides. The hosted closed model was the easiest way to get running on a weak laptop. That is a real advantage for convenience. The open route won on three things that matter more for this kind of tool:

Privacy. A private, fully local mode exists only because open weights exist.
Longevity. Hosted models get deprecated and APIs get shut down. A model you run yourself keeps working offline indefinitely.
Portability. Because the project is not tied to one vendor, moving between providers is a config change and not a rewrite.

For a tool that reads people's screenshots, the person who owns them should decide where they go. Open weights are what make that decision possible.

Before SnapRecall, finding an old screenshot meant scrolling through thumbnails for minutes. Now it means typing a few words.

The Lazy Payoff

It actually saves you a ton of time. Instead of scrolling forever to find a specific screenshot, you just type whatever you remember about it. I dropped the project in the friend's group chat and the hype is real ,everyone wants this to exist, so I'm dropping the whole thing in a few days as soon as possible :)

Prize Categories

Best Use of Gemma: SnapRecall's local mode is built around Gemma. It uses Gemma (for example gemma3:4b) to read screenshots and EmbeddingGemma for semantic search, all running through Ollama on the user's own machine, and it is selected with a single setting.

Best Use of GitHub Copilot: I used GitHub Copilot to plan the architecture and to speed up parts of the code. The decisions about what to build, how the search works and how the indexer behaves were mine, and the project runs end to end.

Thank you for reading. If you try SnapRecall on your own screenshots folder, I would like to hear how it goes. Issues and ideas are welcome on the repo.

GlowUp Local: Using Open-Source AI to Help Local Businesses Improve Their Online Visibility

Anmol — Sun, 18 Oct 2026 18:04:50 +0000

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

TL;DR

What: GlowUp Local is a working prototype for AI-powered local business visibility and competitor intelligence.
Problem: Small business owners may struggle to understand their online presence, evaluate nearby competitors, and decide which improvements to prioritize.
AI: Gemma via Hugging Face is the language-model component intended to turn structured business information into actionable recommendations.
Tech stack: Python, FastAPI, React, Vite, Gemma, and a planned Google Places API integration.
Target users: Hotels, guesthouses, restaurants, cafés, local shops, and other small businesses in India.
Business potential: Pay-per-audit reports, subscriptions, and partnerships with local marketing professionals.

What if A small business owner could understand their nearby competition, identify gaps in their online presence, and get practical suggestions to improve their visibility on Google Search and Google Maps without becoming an SEO expert?

That's the idea behind GlowUp Local, an AI-powered local visibility and competitor intelligence tool I'm building.

I'm exploring how open-source AI can help local businesses make better-informed decisions about their online presence, while also exploring a potential side hustle that solves a real business problem.

My initial target market is India, starting with businesses such as hotels, guesthouses, cafés, restaurants, and other local businesses in specific neighborhoods and areas.

What I Built

GlowUp Local is a working prototype designed to help local businesses understand their online presence, learn from available information about nearby competitors, and discover possible improvements they can make.

The idea started with a place I know: Varanasi, India.

When people visit Varanasi, they often have questions. Where should they stay? Which hotel or guesthouse should they consider? Which restaurants are worth exploring? Where can they find local products?

Discovering a city can be confusing when you're unfamiliar with it.

But this got me thinking about the other side of the same problem: the businesses that visitors might never discover.

Varanasi has hotels, guesthouses, cafés, restaurants, saree shops, and many other local businesses. Across India, countless small businesses are trying to reach customers in their own neighborhoods.

Some businesses may already offer excellent products or services but struggle to communicate their value online. Others may have incomplete business information or lack the time and expertise to understand how they compare with nearby competitors.

Traditional SEO tools can provide plenty of metrics, but understanding those metrics and turning them into practical actions can be difficult for someone who is busy running a business.

I wanted to explore a simpler approach.

What if a business owner could get a clearer picture of their online presence and a prioritized list of possible improvements in one place?

How GlowUp Local works

The intended workflow is straightforward:

Business information: The owner provides details such as their business name, category, address, and the products or services they offer.
Nearby competitor discovery: The application uses Google Places API to retrieve available information about relevant nearby businesses.
Structured comparison: The application organizes available business information into data that can be used for an evidence-based comparison.
AI-powered recommendations: Gemma processes the structured data to help generate prioritized recommendations and practical action steps.
Actionable insights: The goal is to help business owners understand what they could improve and decide what to work on first.

For example, a restaurant might receive suggestions to communicate its menu more clearly, improve available business information, describe its services more effectively, or create a better process for asking satisfied customers for honest reviews.

The planned recommendation workflow also includes evidence references, confidence levels, and local marketing content drafts.

The important distinction is that GlowUp Local is not intended to generate generic SEO advice and present it as a personalized competitor analysis. Its recommendations should be grounded in the information available to the application.

And I'm not promising anyone the number-one position on Google. Search visibility depends on many factors, and no tool can guarantee that outcome.

The goal is to make local business intelligence easier to understand and turn it into practical next steps.

Why could this become a side hustle?

GlowUp Local addresses a problem that local businesses may be willing to pay to solve: understanding their online presence without having to perform all the analysis themselves.

Potential customers include:

Hotels and guesthouses that want to improve how they present themselves online.
Restaurants and cafés that want to communicate their offerings more effectively.
Local shops and service providers that want to understand their nearby competitive landscape.
Freelancers and small marketing agencies that want to assist local businesses with data-informed recommendations.

I'm exploring several possible business models: pay-per-audit reports, a freemium offering, recurring subscriptions, or partnerships with local marketing professionals.

These are potential business models, not validated revenue streams. I haven't acquired my first paying customer yet.

Before monetizing the product, I need to establish whether its recommendations are useful, whether business owners act on them, and whether they are willing to pay for the value provided.

Demo

Code Repository

GitHub: https://github.com/AnmolCanCodes/GlowUp-Local

Why Open Innovation Matters

Open innovation matters to GlowUp Local because I want to explore how accessible AI technology can be used to solve a specific problem for small businesses.

I'm using Gemma via Hugging Face as the language-model layer for generating business recommendations from structured local business and competitor data.

The intended workflow is to retrieve available business information, organize it into structured data, and use Gemma to help produce prioritized recommendations, actionable steps, evidence references, confidence levels, and local marketing content drafts.

Instead of treating an AI model as a black box that simply produces impressive-sounding answers, I want the application to connect its recommendations to available evidence and make the resulting advice useful to a business owner.

Open-weight models such as Gemma give developers an opportunity to experiment with AI-powered applications without depending exclusively on proprietary model providers. Depending on the model's license, deployment setup, and available computing resources, developers can explore different ways to run models and build workflows around their specific use cases.

This is particularly relevant to my project because my target customers are small businesses that may not have the budget to hire SEO specialists or purchase expensive marketing tools.

If I can make business information easier to understand and turn it into useful actions, GlowUp Local could help make certain forms of business analysis more accessible.

Open-source tools also let developers inspect and improve the surrounding application code, experiment with alternative approaches, and invite contributions from the wider developer community.

However, open-source AI is not automatically free to operate, accurate, or commercially viable. Inference costs, data quality, model limitations, and the reliability of the recommendations still need to be addressed.

For me, open innovation is about using accessible technology to build something useful, testing it against a real-world problem, and improving it through experimentation and community feedback.

Prize Categories

Gemma: Gemma helps this project by acting as the AI decision-support layer for the business audit.
The web app:

finds the business and nearby competitors using Google Places
compares the business against them
passes that structured data to Gemma
asks Gemma to generate:
    prioritized recommendations
    action steps
    evidence references from the audit
    confidence levels
    content drafts for local marketing

So Gemma is what turns raw comparison data into useful advice like:

“Improve your GMB profile”
“Add service-area keywords”
“Create more location-specific content”
“Improve review and rating signals”

This is exactly what the project is about: helping local businesses understand where they stand and what to do next.

GitHub Copilot : GitHub Copilot used to help me whenever there are bugs and errors in my codes, it fix them

Traction: Where the Project Stands

GlowUp Local is currently at the working-prototype stage.

I haven't acquired my first real user or test customer yet, so I can't claim validated customer feedback, paying users, or measurable business results.

I want to learn:

Which recommendations they find genuinely useful.
Whether the available competitor information helps them identify meaningful improvements.
Whether the reports are understandable to someone without SEO expertise.
Which features they would actually pay for.
What information is missing or unreliable.

This feedback will help me decide what to improve before investing more time in advanced features or monetization.

I'd rather validate the product with real businesses than assume that generating AI recommendations automatically creates value.

Tools & Frameworks

Here's the technology stack behind GlowUp Local:

Python: Backend development and application logic.
FastAPI: Backend API layer.
React + Vite: Frontend application.
Google Places API: Planned integration for nearby-business discovery and available place information.
Gemma via Hugging Face: Open-weight language model used for AI-powered business recommendations. **GitHub

These tools bring together full-stack development, business data, and open-source AI to explore a practical local business use case.

GroundTruth: An Open-Source AI Quest Platform That Rewards Real-World Exploration

Anmol — Sat, 10 Oct 2026 07:42:50 +0000

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

What I Built

We have apps to track our steps, apps to track our calories, apps to track our productivity, and even apps that remind us to take breaks from using apps.

There's something slightly ironic about that.

We spend so much time looking at screens, even when we're trying to build healthier habits.

But what if an app didn't just tell you to go outside? What if it gave you an actual reason to do it?

That's the idea behind GroundTruth.

GroundTruth is an open, local-first outdoor quest platform that turns everyday exploration into real-world challenges, photo-based submissions, and measurable progress.

The world is the game. Your actions are the achievements.

Instead of simply counting steps or tracking activity, GroundTruth gives users small outdoor quests that encourage them to observe and explore their surroundings.

Some examples:

Sky reflection: Photograph the sky reflected in a puddle or window.
Notice tiny textures: Find an interesting texture on a public path, rock, or tree bark.
Cloud imagination: Look at the clouds and photograph an unusual shape from a safe location.

You don't need a mountain, a hiking trail, or an entire weekend to participate. Sometimes, all you need is five minutes and a reason to notice something you usually walk past.

How it works

Choose your moment: Select a time slot such as morning, evening, or night.
Discover a quest: Browse outdoor challenges with instructions, difficulty levels, estimated time, and proof requirements.
Go outside: Complete the actual task in the real world.
Submit evidence: Upload a photograph of your completed challenge.
Earn XP: Approved submissions earn experience points and contribute to levels, streaks, and badges.
Explore together: Compare weekly XP through regional leaderboards covering country, state, and city.

The important part is that the actual challenge happens outside the application. The phone is there to introduce the quest and record the accomplishment, not to become the activity itself.

GroundTruth is designed for people who want to explore their surroundings, build outdoor habits, and make everyday experiences a little more interesting.

Demo

The field journal introduces the experience with one simple invitation: "A little less screen. A little more world."

The Explore section lets users discover quests based on their selected time slot.

Quest examples include Sky Reflection, Notice Tiny Textures, and Cloud Imagination.

The leaderboard adds a friendly competitive element by ranking users according to approved weekly quest XP.

Code

GitHub Repository: https://github.com/AnmolCanCodes/groundtruth

The project is open source. Feel free to explore the implementation, inspect the architecture, and experiment with it.

How I Built It

I wanted GroundTruth to have a straightforward architecture where the core application logic and AI functionality remain independent.

Technology stack

Component	Technology
Frontend	React + Vite
Backend	Python + FastAPI
Database	SQLite
ORM	SQLAlchemy
Authentication	JWT
AI integration	Hugging Face InferenceClient
Open-weight model	Google Gemma 7B Instruct

Architecture

The application follows this general flow:

              React + Vite
                   |
                   v
                FastAPI
                   |
          +--------+--------+
          |                 |
          v                 v
    Core Application     AI Service
          |                 |
          v                 v
     SQLAlchemy        Hugging Face
          |             InferenceClient
          v                 |
        SQLite              v
                         Gemma 7B

Why I separated AI from the reward system

This was one of my important engineering decisions.

I didn't want an LLM to have unrestricted authority over user rewards.

In GroundTruth, Python handles the deterministic application logic:

Quest progression.
Submission processing.
XP calculations and rewards.
Level progression.
Date-based streak tracking.
Badge unlocking.
Weekly regional leaderboard calculations.

AI works as an assistant layer rather than the authority controlling the entire application.

Using Gemma

GroundTruth integrates Google's open-weight Gemma 7B Instruct model through Hugging Face's InferenceClient.

I use Gemma for text personalization, with the goal of adapting quest descriptions to individual preferences without changing the underlying challenge requirements.

The application also supports optional AI-assisted image relevance assessment. This is configurable rather than mandatory, and basic upload validation is handled separately by the backend.

I wanted to keep the AI service replaceable so that changing the model or inference configuration wouldn't require rewriting the application's core logic.

The result is an application where AI adds flexibility without becoming a dependency for every operation.

Why Does Open Innovation Matter?

For GroundTruth, open innovation is not just about using an open-weight model because it's available.

It's about having control over how AI fits into the application.

I didn't want the entire experience to depend on a single proprietary AI provider or a closed ecosystem.

Here's why open technology matters for this project.

1. Model flexibility

Using Gemma gives developers an open-weight model that can be integrated into a self-hosted application.

The AI layer is separated from the core backend, making it easier to experiment with different compatible models and inference configurations.

2. Data ownership and self-hosting

GroundTruth uses SQLite and local file storage for its self-hosted setup.

Developers can run their own instance and maintain control over their application data instead of depending entirely on a centrally operated platform.

3. Less vendor dependency

The personalization layer doesn't need to be permanently tied to one closed AI provider.

Developers can explore different models and deployment approaches as their requirements evolve.

4. AI where it actually makes sense

I also believe that not every application decision needs an LLM.

GroundTruth uses AI for assistance and personalization, while important operations such as reward calculations and progression remain deterministic.

This makes the application more predictable and easier to reason about.

For me, open innovation means having the freedom to make those architectural decisions rather than accepting a closed provider's limitations.

And most importantly, it lets me experiment with AI in a way that encourages people to spend more time in the real world, not more time interacting with an AI interface.

Prize Categories

Gemma:

GroundTruth uses Google's open-weight Gemma 7B Instruct through Hugging Face's InferenceClient to personalize outdoor quest descriptions based on user preferences, while preserving the original challenge requirements.

I chose Gemma because I wanted an AI layer that could be experimented with and configured independently of the core application. AI assists with personalization, while Python handles quest validation, XP, badges, and leaderboard calculations deterministically.

The idea is simple: use open-weight AI to make real-world exploration more personal, not to make another screen more addictive.

That's why I'm submitting GroundTruth for the Best Use of Gemma category.

A little less screen. A little more world. 🌿

Thanks for checking out GroundTruth. I'd love to hear what outdoor quest you'd add to it!

DEV Community: Anmol

Somewhere Out There, Forgotten Accounts Still Have My Name, I Went Looking: So I built Ghostbook, a Gemma-Powered Map of Your Forgotten Accounts.

The story

What I Built

What it does

How It Fits "Ghost in the Machine"

Gemma powers three features:

Demo

Code

AnmolCanCodes / Ghostbook

Ghostbook

The problem

How I Built It

One client, any Gemma

Being honest about what leaves your machine

Security design

Things that were harder than they looked

Why Does Open Innovation Matter?

The Spirit of It

Prize Categories

I Had 5,000 Screenshots and Couldn’t Find Any, So I Built: SnapRecall:Type What Text You Remember, Find the Screenshot

What I Built

How I got the idea

Two ideas, one choice

Who it is for

Features

Demo

Code

AnmolCanCodes / snaprecall

SnapRecall:Find any screenshot by typing what you remember about it..Built for the Hacktoberfest DEV Challenge, Week 3 (theme: "Slow and Steady")

SnapRecall

Table of contents

How I Built It

The stack

The pipeline

Finding screenshots: the watcher and the queue

What the model does with each screenshot

Why the search is hybrid

Slow and steady, on purpose

One codebase, two ways to run

Why Does Open Innovation Matter?

The Lazy Payoff

Prize Categories

GlowUp Local: Using Open-Source AI to Help Local Businesses Improve Their Online Visibility

TL;DR

What I Built

How GlowUp Local works

Why could this become a side hustle?

Demo

Code Repository

Why Open Innovation Matters

Prize Categories

Traction: Where the Project Stands

Tools & Frameworks

GroundTruth: An Open-Source AI Quest Platform That Rewards Real-World Exploration

What I Built

How it works

Demo

Code

How I Built It

Technology stack

Architecture

Why I separated AI from the reward system

Using Gemma

Why Does Open Innovation Matter?

Prize Categories

Gemma: