DEV Community: maitri-vv

Pick For Us: I trained a small movie model to end the endless ‘you pick’ loop

maitri-vv — Mon, 26 Oct 2026 06:45:13 +0000

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

What I Built

A movie night has a surprisingly tedious opening scene.

“Something good?”

“Sure. You pick.”

Forty thumbnails later, nobody has picked anything.

I built Pick For Us around a small promise: reduce the work of choosing. It opens with an actual recommendation, asks for no uploads or account connections, and lets you add a few favorite films only if you want a more personal pick.

There are two modes: Just me and Both of us. In the second, each person can tap up to five favorites. The app looks for a recommendation supported by both sets of taste signals and explains the connections separately.

It presents one main pick, a small set of alternatives, and a “That's the one” button that lets you stop choosing. Genre filtering and “Seen it / next” are there when needed. There is no endless feed.

The default works with no input. It uses community ratings with a support adjustment, so a film with a handful of glowing reviews does not automatically outrank a well-supported favorite.

Code

GitHub: https://github.com/maitri-vv/pick-for-us
Site: https://maitri-vv.github.io/pick-for-us/

How I Built It

A real dataset and a model trained from scratch
I used the MovieLens latest-small September 2018 snapshot, containing 100,836 ratings from 610 users across 9,742 source movies. After a training-only minimum-support filter, the application catalog contains 1,859 films.

The model is based on EASE, a linear collaborative-filtering method. It learns how likes for one film help predict likes for others. NumPy fits its regularized closed-form solution; it is not an LLM prompt pretending to be a recommender.

The training pipeline:

Sort each user's ratings by time and hold out their latest 20%.
Build a binary interaction matrix from training ratings of four stars or higher.
Fit EASE with regularization of 80 and a zero diagonal.
Retain the largest 80 positive outgoing weights per movie and export them.
Evaluate that exported sparse model, rather than a larger model that the app never serves. The sparse positive truncation is my deployment adaptation of EASE. I did not tune its settings through a search over test-set results.

What the tests actually showed

Experiment	Users	Model Recall@10	Baseline Recall@10
Complete historical positive profile	573	11.030%	6.097%, training popularity
Five recent training likes, production scoring	563	9.822%	4.845%, community quality

Recall@10 measures how much of a user's held-out liked set appears in the top ten. It is not a probability of enjoyment, and I am not calling it “98% accuracy.”

The second experiment is closer to the interface: it uses only five likes and the same single-person scoring formula served by the backend. However, the evaluator still excludes all previously rated training films, which a genuinely new visitor has not supplied. Real onboarding performance still needs a user study.

There are other limits. The split is chronological per user, not one global date cutoff. The catalog is historical and leans toward English-language films. These are development-snapshot experiments, not a claim of state-of-the-art research results.

How the two-person decision works
Each person gets an affinity score derived from learned weights. After normalization, the shared score combines 65% of the weaker affinity with 35% of the pair's average, plus a small community-quality component.

That means a very strong signal for one person cannot completely erase a weak signal for the other. It is a transparent product rule—not a learned or user-validated guarantee of fairness. The interface shows each person's relative affinity and the selected favorites contributing positive learned weights.

Frontend and backend
React handles the responsive interface. The backend exposes catalog search, recommendation scoring, and evaluation metadata. The hosted app uses Vinext on a server runtime; the downloadable package is a standard Next.js project with the same frontend, handlers, and learned model.

The trained weights ship with the backend. There are no model-service keys, streaming-account integrations, user uploads, or GPU requirements. User-selected IDs are sent to this server for scoring; the app does not intentionally persist a personal profile.

Twelve checks exercise the actual recommendation handler and model, including invalid input, seen-film exclusion, genre filtering, and two-person symmetry. Browser checks verify the complete selection-to-result flow and the mobile layout. ChatGPT/Codex assisted the implementation and testing.

Why Does Open Innovation Matter?

A small, inspectable model is enough for this job. I can show how the coefficients were learned, rerun training, compare against baselines, and explain the serving formula without outsourcing the decision to a proprietary chat API.

The distinction between open application code and data permissions matters: my application code is MIT-licensed, while the MovieLens-derived artifacts retain GroupLens's research-use terms. This is a non-commercial research demo; a commercial product would need suitable permission or a different dataset.

The app does not know current streaming availability, age suitability, or recent releases. Its poster-like cards are original typographic graphics, not official film artwork. It links to IMDb so visitors can inspect details before deciding.

I haven't measured minutes saved. The product's “Slow and Steady” contribution is the workflow: arrive with nothing, optionally offer a few tastes, get one grounded suggestion, and give yourself permission to stop scrolling.

Credits

F. Maxwell Harper and Joseph A. Konstan, The MovieLens Datasets: History and Context, 2015. Dataset and terms. No endorsement by GroupLens or the University of Minnesota is implied.
Harald Steck, Embarrassingly Shallow Autoencoders for Sparse Data, 2019.
NumPy, SciPy, React, Next.js, Vinext, and their contributors.
DM Sans and Manrope through Google Fonts. The original dataset download was unavailable during the build, so training files were obtained from the smanihwr/ml-latest-small mirror. File hashes and the original data terms are included for provenance.

Hearth-Describe a workspace. Preview the rooms. Create them in Notion.

maitri-vv — Mon, 19 Oct 2026 06:55:35 +0000

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

What I Built

A person writes one sentence. Hearth designs the pages, databases, properties, and views, shows the result before anything is written, then builds the parts the public Notion API can create. Whatever the API cannot do is returned as a short companion: exact clicks, in order, on the right page.

The problem

Notion is generous and easy to get lost in. A new workspace starts as a blank page. The useful structure — a home page, a database per kind of work, a status, a due date, a board, a calendar, a relation between them — takes a long time to assemble, and most people stop halfway. They end up with one table and a dozen loose notes.

Templates exist, but a template is someone else’s life. A student, a studio, and a household do not want the same columns. They want the shape of their sentence.

The missing step is the one in between: turn a description into a design, let the person look at it, then create only what Notion will actually accept.

Who it is for

Anyone who can describe the room they need and has a Notion account. The first version is aimed at a single person on a free workspace: a student setting up a term, a researcher setting up a desk, a small studio setting up clients and a calendar. It is not a team installer and it does not ask for an admin.

What I built

Hearth is a web app with four moves.

Write a brief. One box. A sentence or two is enough. Mood and job can sit in the same line.
Read the preview. A sidebar of rooms, the page as it will read, the database as a board or a calendar, the colours, and a split between “this will be created” and “this stays by hand.”
Rehearse. The same builder runs against an in-memory Notion. Nothing in the real workspace changes. The log shows every page, view, and relation that would be sent.
Create. A personal access token builds the workspace as that person. The token is used for the build and then forgotten. It is not stored.

There is also a catalogue. Each row says one of three things: Notion offers this, Hearth creates this, or the person still does it by hand. Every row links to the official page it came from.

One example, all the way through

This is the brief I kept on the desk while building:

Aesthetic + warm + rich. A student dashboard for assignments, revision and projects.

Hearth reads three decisions in that line.

The mood is warm and rich, so the palette is clay, cream, olive, and ink, and the workspace is named The Study.
The job is a student dashboard, so the hub is Courses.
The nouns are assignments, revision, and projects, so those become the other three databases.

The preview then shows a small house, not a pile of features.

Room	What it is
The Study	The front page. A short introduction, the list of rooms, and the colour note.
This week	Only what is due in the next seven days, plus live views of the databases.
Courses	The term, named. Other databases point here.
Assignments	A status, a due date, a type, an estimate in hours, and a course.
Revision	A topic, a confidence, a method, and the next review date.
Projects	Longer work, with the outcome written in one sentence.
How this space works	What was created, and the clicks that are still yours.

Assignments opens on a board grouped by status, and also has a calendar on Due. Starter rows are real enough to judge the design: Mechanism worksheet belongs to Organic Chemistry, and that link is a relation, not a name typed into a text field. Three rows per database. Enough to see the board. Few enough to delete.

The companion does not say “set up automations.” It says: open Assignments, add one automation, trigger it when Status becomes Done, and write today’s date into Completed. Same tone for the cover, the reminder on Due, and the template for a new assignment.

How it works

The pipeline is five steps. Each one can fail without taking the others down.

1. Design.

With no model key, an atelier reads the brief. It picks a domain (student, research, studio, household, product, writing, or personal), a mood, and the databases named in the sentence. If the sentence names nothing, the domain supplies a small default set. Relations are added only when both sides exist. A board is grouped only by a status or a select. A calendar is bound only to a date.

If a Gemma key is set, Gemma drafts the same kind of plan. The draft is repaired before it can reach Notion: unknown property types are dropped, a board without a group is dropped, a relation to a missing database is dropped. If the repair leaves nothing usable, the atelier plan is kept and the preview says so.

2. Consult the docs.

Before the preview is shown, Hearth fetches the official pages it is about to rely on: creating a page, creating a database, data source properties, working with views, and personal access tokens. The index those pages come from is Notion’s public llms.txt. If a fetch fails, the link and the reason are still shown. The build does not invent a capability because a page was offline.

3. Validate.

Every property and every view is checked against a catalogue. The catalogue is the contract. “Notion supports charts” and “this build will create a chart” are different sentences. Charts, maps, buttons, and formulas are left as manual steps, because a bad formula can fail an entire database, and a chart depends on the workspace plan.

4. Preview.

The person walks the rooms. Switching a database from Board to Calendar uses the starter rows, so October shows the worksheet on the day it is due. Nothing has been written to Notion yet.

5. Build.

The builder speaks Notion API version 2026-03-11. The order matters.

Create the home page, then the other pages.
Create each database with its first data source and its default table.
Add relations only after both data source ids exist.
Rename the default table, then add the board, calendar, list, gallery, timeline, and filtered tables.
Place linked views of those databases on This week.
Add starter rows in dependency order, so a course exists before an assignment points at it.
Append the companion to How this space works.

A step that Notion refuses is recorded, skipped, and rewritten as a manual step. The rest of the workspace still gets created.

What I used, and what I refused to pretend

Notion publishes enough to build this without private source code.

Source	What I took from it
Help Center	What pages, databases, views, templates, and automations mean to a person.
Developer docs	The request shapes: pages, data sources, properties, views, filters, parents.
`llms.txt`	The map of those docs, so the app can fetch the page it needs instead of guessing.
The API	The actual create calls. Available on every plan, including Free, with a personal access token.
Notion MCP	Proof that an assistant can create pages, databases, and views. Hearth does not require MCP. The REST API is enough for a free workspace, and some MCP tools are limited to paid plans with Notion AI.

I kept a hard line between three facts.

Notion offers it. Boards, calendars, galleries, relations, templates, automations, charts.
Hearth creates it. Pages, icons, text and status and date and number and checkbox properties, relations, the views above, linked views, and starter rows.
The person still does it. The cover image, a database template, a date reminder, one automation, and sharing. Buttons are ignored if you send them in a schema write. Charts can be created by the API, but the configuration depends on the plan, so this version does not guess it.

That line is the part I would want a judge to notice. A builder that claims every Notion feature is a builder that fails on the third call.

Decisions I would defend

Preview before write.

The costly mistake is a wrong database in someone’s real sidebar. Rehearsal and the preview exist so the person can say no.

A catalogue, not a one-time reading of the docs.

Reading the documentation once would go stale. The catalogue is checked on every plan. The live docs are consulted for the pages the plan actually uses. When Notion changes a request, one of those two will show it.

Repair the model, do not trust it.

Gemma is optional. The atelier already produces a plan the builder can execute. The model is allowed to change names, rooms, and copy. It is not allowed to invent a property type the API will reject. If it does, that part is removed and named.

A personal access token, not a stored login.

On the Free plan, the workspace owner can create a token and the API will create a private page as them. An internal integration is the other door: it only sees pages shared with it, so the person picks the parent. The token stays in the browser tab for the build. The server does not write it down.

Small on purpose.

A handful of pages, the databases the sentence asked for, three starter rows each. Free workspaces have a block limit. A first version that creates fifty databases is not a kindness.

What went wrong, and what I changed

The first token build failed in a way the happy path did not show.

Notion returns a personal access token as a bot user. I treated every bot as an internal integration and tried to build inside the page the person had edited most recently. That is the wrong parent. A token that belongs to a person is allowed to create a private page at the top of the sidebar. An internal integration is not. The check now tells those two apart.

The page body also used an icon the current API rejects, so the first create died before any database existed. Page writes now use the documented emoji form, and if the block body is refused, the same page is sent again as markdown. When Notion refuses a call, the status and the message are printed in the server log. Before that, the failure lived only inside the response, which made it look like nothing had happened.

What I am not claiming

Hearth does not read Notion’s private source.
It does not turn on automations, upload a cover, or invite a teammate.
Gemma is not required. With no key, the atelier designs the workspace.
A free API does not mean a free model or free hosting. Those are separate costs.
Some MCP tools, and charts, depend on the workspace plan. The first version stays on the calls a free workspace can make.

What I would do next

Keep the catalogue honest as Notion’s API moves. The next useful step is applying a database template once the person has created one, because the API can apply a template and still cannot design it. After that, a public connection so a teammate can authorize Hearth without pasting a token.

The product, as it stands, is the sentence I started with.

Describe the workspace. Look at the rooms. Create the ones Notion will accept. Leave the rest as instructions a person can follow without guessing.

Demo

https://github.com/maitri-vv/

Code

How I Built It

Why Does Open Innovation Matter?

My Agent Session

My First User

Prize Categories

Plain Sight Walk is a walking game that lives in your pocket.

maitri-vv — Fri, 09 Oct 2026 15:18:26 +0000

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

What I Built

Plain Sight Walk is a walking game that lives in your pocket.

Every walk has a secret word, say WANDER. You spell it one letter at a time with things you actually find outside: W is for wall, A is for acorn, N is for nest. Gemma writes you a riddle for each letter and can read it aloud, so the phone stays away. When you find the thing, you photograph it, and an open vision model checks the photo. When the word is complete, the app turns your walk into a photo carousel: each slide is one of your photos, stamped with its letter, the object, and how many kilometres into the walk you took it. The secret word picks the look of the whole set. WANDER becomes "Roadside Almanac", a warm sepia. SHADOW becomes "Chiaroscuro", black and white.

The screen is only for the start and the end. The middle of the experience is looking at things.

Demo

Live app: plain-sight-walk.vercel.app (best in recent Chrome or Edge; it needs WebGPU for Gemma)

Code

Code (MIT):

maitri-vv / plain-sight-walk

Plain Sight Walk

Every walk has a secret word. You spell it one letter at a time with real things you find outside (a leaf, a rock, the sky). Built for the DEV "Touch Grass" challenge.

Everything runs in your browser, with no server and no API key.

Job	Open model	How it runs
Writes the riddles, field notes and closing postcard	Gemma (2B, the Gemma build available in WebLLM)	WebLLM, WebGPU
Checks your photo matches the clue	CLIP ViT-B/32 (ONNX port by Xenova)	transformers.js

Photos are never uploaded. After the first load, models are cached and the app works with no signal.

Run it

python3 -m http.server 8000   # WebGPU needs https or localhost
# open http://localhost:8000 in recent Chrome or Edge, tap "Prepare for the walk"

Deploy (Vercel)

Push this folder to GitHub, then import the repo in Vercel. Framework preset "Other", no build command, no output…

View on GitHub

How I Built It

You cannot play this at a desk. The only way to earn a letter is to stand in front of a real wall, a real patch of moss, a real nest. The riddles are read aloud, so between finds the phone can stay in your pocket. A six-letter word takes about [X] minutes of walking when you actually look. The carousel at the end gives you a reason to look properly: you are composing a photograph, not ticking a box.You cannot play this at a desk. The only way to earn a letter is to stand in front of a real wall, a real patch of moss, a real nest. The riddles are read aloud, so between finds the phone can stay in your pocket. A six-letter word takes about [X] minutes of walking when you actually look. The carousel at the end gives you a reason to look properly: you are composing a photograph, not ticking a box.

It is a static site: no backend, no API key, no database. It is deployed on Vercel straight from GitHub.

Gemma, running in the browser through WebLLM on WebGPU. It writes the riddles, a one-line "look closer" note after each find, and the closing postcard. The app picks the Gemma build WebLLM offers; in my run that was [model id shown in the app].
CLIP, running through transformers.js. This does zero-shot image classification. Your photo is scored against the twenty possible objects plus distractors like "a person" and "a computer screen". A match means the target is the top label above a confidence threshold.
The device's own GPS. The app adds up distance as you walk and keeps only the running total. Coordinates are never stored or sent anywhere.
A service worker caches the app shell. WebLLM and transformers.js cache the model files themselves, so after the first load the app can run with no signal.
A canvas renderer composes the carousel as 1080x1350 slides, ready to save or share.

Three design decisions mattered more than any code:

The object for each letter comes from a fixed table; Gemma writes the language around it. My first instinct was to let the model choose a thing for each letter. But a small model sometimes picks something you cannot photograph, and CLIP is far more reliable on common objects. Splitting the work this way made the game dependable outdoors, where there is no retry button for a bad clue.
Gemma is told to give attention, not facts. Small models invent facts about nature, confidently. So the field notes only invite you to look closer. [If you tested the unconstrained version, say what it did.]
The game never calls you wrong without an exit. CLIP will sometimes be mistaken, so there is always a "Count it anyway" button. A walk is not an exam.

Why Does Open Innovation Matter?

It works where signal does not. A walk is exactly where signal disappears. Both models run in the browser and are cached, so [describe what you saw when you went offline].
Your photos stay on your phone. A game that asks you to photograph your neighbourhood should not upload it. With open weights running locally, there is nothing to upload them to.
It costs nothing to run. There is no per-request bill, so I can leave the demo public without worrying that a stranger's walk costs me money.
I can swap the model. The app selects Gemma from WebLLM's list and CLIP is one line. When a better small model appears, the game improves with a small edit.
Where a closed approach would have been worse: [your honest comparison, or delete this line].
What Went Wrong
The first download failed on my network. My first attempt stopped at Cache.add() encountered a network error. The DevTools Network tab showed the tokenizer.json request returning a redirect, and the file it redirected to failing. CLIP, which comes from the same site, loaded fine, so Hugging Face itself was reachable; something between me and its file host was not. [How you resolved it: a hotspot, secure DNS, another network, or not at all.] The lesson: an offline-first app needs a graceful path when the first download fails. The app now retries once and then falls back to built-in riddles instead of stopping.
My own service worker served me a stale page. I cached the app shell "cache first", so my fixes did not show up and I debugged old code for a while. App files are now fetched network-first.
The first load is large, roughly 2 GB [check your own number under DevTools, Application, Cache Storage], so it should be prepared on Wi-Fi before you leave home.
GPS can pause when a phone screen locks. I added a "keep screen awake" option, at a battery cost. [Your own result.]
CLIP is sometimes wrong, and GPS is only accurate to roughly a few metres under open sky, less under trees. Treat the kilometres as "about".

Prize Categories

Best Use of Gemma: Gemma is the voice of the whole game, and it runs entirely on the player's device.

Built for Touch Grass. Go outside; it is better than the screen.

FollowUp: I Built My Dad a Private AI That Remembers Where His Messages Came From

maitri-vv — Sat, 03 Oct 2026 12:27:22 +0000

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

What I Built

My dad remembers the thing.

He just doesn't always remember where it came from 🥲 or what he still needed to do about it.

A society payment. An AC offer. A quotation someone sent as a PDF. A document buried somewhere in a family WhatsApp chat.

The information exists.

Finding it again is the problem.

So I built FollowUp for him.

FollowUp turns buried conversations into things you actually need to act on.

FollowUp is a private-first AI memory assistant that turns scattered messages, notes, documents, and screenshots into something you can actually ask questions about.

You can ask things like:

"When is the society payment due?"
"Who sent me that AC offer?"
"Where did I get that quotation?"
"What payments do I need to make?"
"What am I forgetting?"

But FollowUp isn't designed to just give you an answer.

It shows you the source behind the answer.

If FollowUp tells you that the society maintenance is ₹4,800 and due on 7 October, you can open the result and see the original message, sender, group, and date that the answer came from.

That makes the result traceable instead of just another AI response.

The feature I built specifically for my dad

The most interesting part ended up being "What am I forgetting?"

Instead of requiring my dad to remember the right question, FollowUp looks through imported memories for things that appear actionable:

payments
renewals
requests
offers
deadlines

It turns those buried messages into actionable cards.

For example:

SOCIETY MAINTENANCE

₹4,800

PAY BY 7 October 2026

Click it, and FollowUp opens the original message that caused it to appear.

So the loop becomes:

find the thing → understand why it matters → verify where it came from

For the public demo, I use synthetic memories rather than uploading my dad's private conversations.

Demo

Live Demo: https://hacktoberfest-followup-peach.vercel.app/

The demo is built around the actual problem rather than a generic chatbot flow.

Open the demo.
Click Load demo Dad data.
Open "What am I forgetting?"
See payments, requests, and offers surfaced from the imported memories.
Click an actionable item.
Inspect the exact original source.
Ask a natural-language question such as:
- "Who sent me the AC offer?"
- "When is the society payment due?"
- "Where did I get the quotation?"
Get a grounded answer with the supporting memories.

The public deployment currently starts with an empty browser memory store by design. The demo data is loaded explicitly so nobody's private history is part of the public deployment.

Code

GitHub: https://github.com/maitri-vv/FollowUp

The project is built with:

Next.js
React
Transformers.js
Gemma 3 270M IT
browser-side WASM inference
IndexedDB
semantic + lexical retrieval
optional Backboard RAG

The repository contains the ingestion/parsing logic, retrieval pipeline, local Gemma inference, actionable-memory detection, source tracing, and optional Assisted Mode.

How I Built It

The main constraint was simple:

AI shouldn't be a chatbot bolted onto the product. It should be part of how FollowUp works.

The core architecture looks like this:

WhatsApp exports / notes / documents
              ↓
        Local ingestion
              ↓
           Chunking
              ↓
     Embeddings + retrieval
              ↓
     Local open-weight Gemma
              ↓
    Grounded answer + sources

1. Importing memories

FollowUp turns imported information into structured memories containing things such as:

source
sender
group
date
category
original message

WhatsApp exports can be parsed into individual messages so they can be retrieved independently.

The public demo also includes synthetic Dad memories so the entire flow can be tested without using real personal data.

2. Retrieval

FollowUp uses both semantic retrieval and lexical matching.

Semantic retrieval helps when the question and the original message use different words.

Lexical matching helps preserve exact information such as:

names
dates
amounts
"pay"
"renewal"
"quotation"
"before Friday"

The results are combined before the answer layer sees them.

This matters because personal-memory search isn't just a keyword problem.

If my dad asks:

"Who sent me that AC thing?"

the useful memory might actually say:

"Voltas AC service package at the festival offer price."

Semantic matching helps connect those ideas, while lexical matching protects the exact details.

3. Gemma runs locally

The open-weight model at the core of FollowUp is Gemma 3 270M IT.

I run it through Transformers.js using browser-side WASM inference.

That gives FollowUp a local inference path without requiring a hosted LLM for Private Mode.

The model receives retrieved context and generates an answer from that evidence.

I also added a deterministic grounded-answer layer for common memory tasks such as payments, senders, locations, and actionable items.

That makes common queries faster while still keeping Gemma available as the general language layer.

4. Grounded answers

FollowUp is deliberately conservative.

The retrieval layer provides the evidence.

The answer layer is instructed to answer from that evidence rather than inventing missing details.

If the available memories don't contain enough information, FollowUp should say so.

And when an answer is produced, the user can inspect the underlying memory.

For a personal-memory product, I cared more about:

"Show me why you think that."

than making the assistant sound confident.

5. "What am I forgetting?"

This is where retrieval becomes more than a search box.

FollowUp identifies imported memories containing actionable signals such as:

payment amounts
due dates
renewal dates
requests
offers
deadlines

It extracts the relevant action and date and presents those memories as cards.

For example:

PAYMENT

Society maintenance

₹4,800

PAY BY 7 October 2026

Society Admin · Green View Society

The card is clickable, so the user can immediately inspect the evidence behind it.

6. Optional Assisted Mode

FollowUp also has an optional Assisted Mode using Backboard.

In this mode, retrieved memories can be sent to Backboard for hosted RAG assistance.

I deliberately kept this separate from Private Mode.

Private Mode is designed around keeping imported memories in the browser and running the open-weight model locally.

Assisted Mode is an explicit choice to use hosted assistance.

I also added deduplication to the Backboard memory sync so repeatedly syncing the same imported memories doesn't blindly create duplicates.

What I Tested

I tested FollowUp with a synthetic WhatsApp conversation containing realistic examples of the problem:

a ₹4,800 society maintenance payment
an AC service offer from Rajesh
a quotation sent as a PDF
an electricity bill request
a bank statement sent in a family chat
an LIC renewal reminder
repeated references to the same offer and quotation

The import worked, and the main natural-language queries returned the expected information.

The important test wasn't simply whether an AI model could answer a question.

It was whether FollowUp could answer the question and let me trace the answer back to the original memory.

That source trail is the part I wanted to build for my dad.

Why Does Open Innovation Matter?

FollowUp deals with exactly the kind of information people may not want to send to a third-party AI service:

family conversations, reminders, documents, payments, and personal history.

That made the choice of open-weight AI more than a technology preference.

FollowUp's Private Mode can run its language model locally in the browser through Transformers.js.

The basic path is:

Personal memories
       ↓
    Browser
       ↓
Local retrieval
       ↓
Local Gemma inference
       ↓
     Answer

A hosted LLM isn't required for that core path.

That gives the product a different privacy boundary from a design where every personal memory has to be sent to a remote model before it can be useful.

It also gives me control over the model layer.

I can experiment with different open models, change the inference setup, change the retrieval strategy, and keep the application architecture under my control.

There is a tradeoff.

Running a model locally in the browser is slower than calling a large hosted model.

But for FollowUp, that tradeoff is meaningful.

If I'm building something whose job is to help remember personal conversations, I don't want uploading an entire history to a closed API to be the default requirement.

Open innovation made the privacy-first version of FollowUp possible.

My Agent Session

I used DevRelay during the submission workflow to inspect the project, verify the live Hacktoberfest Weekend Challenge requirements, and prepare this submission.

The curated agent session is publicly available here:

https://dev.to/agent_sessions/preparing-followup-for-the-hacktoberfest-weekend-challenge-with-devrelay-mhdiqn

Preparing FollowUp for the Hacktoberfest Weekend Challenge with DevRelay

You

Use DevRelay to inspect the current FollowUp project and tell me what DevRelay capabilities are relevant to my Hacktoberfest Weekend Challenge submission.

FollowUp is already built and deployed.

Public repository: https://github.com/maitri-vv/FollowUp
Live demo: https://hacktoberfest-followup-peach.vercel.app/

I specifically want to qualify for the DevRelay prize.

Do not modify any code yet.

First:
1. Inspect the current FollowUp project.
2. Use DevRelay to inspect the Hacktoberfest Weekend Challenge and DevRelay information.
3. Identify how DevRelay can make a genuine contribution to this project or its submission workflow.
4. Pay particular attention to Agent Sessions because I need to include the resulting session in my DEV submission.
5. Tell me exactly what you recommend doing next.

Do not rewrite or refactor FollowUp.

Agent

I'll inspect FollowUp locally and pull live Hacktoberfest/DevRelay rules so the prize-track advice matches the current challenge, not last year's PR-based Hacktoberfest.

▸ get_knowledge_document topic: hacktoberfest

Input

topic: hacktoberfest

Output

Hacktoberfest 2026 is run by MLH and DEV. Pull requests no longer count. DEV Challenges are the submission path. Install-and-log-in to DevRelay is a Tools sticker. Challenge prompts and prizes are live data, not in this static guide.

▸ get_knowledge_document topic: dev-challenges

Input

topic: dev-challenges

Output

You enter by publishing a DEV post with the required tag and template. AI is allowed with disclosure. Optional: embed an agent session. Weekend Challenges usually allow one submission per person. New work during the entry window.

▸ get_challenges page: 1, per_page: 20

Input

page: 1, per_page: 20

Output

Active: Hacktoberfest Weekend Challenge: Build for a Friend (id 78, slug hacktoberfest-weekend-2026-10-01). Starts 2026-10-02T02:00:00Z, ends 2026-10-05T06:59:00Z. Prompt: open-source AI at the core, built for a friend or loved one. Writing quality weighted most heavily. DevRelay agent session encouraged, not a cash category.

▸ mlh_connection_status {}

Input

{
}

Output

Connected. DEV read/write scopes present. Identity redacted.

▸ list_agent_sessions {}

Input

{
}

Output

No existing agent sessions on this DEV account.

▸ get_my_articles state: all

Input

state: all

Output

Unpublished Hacktoberfest Weekend Challenge draft exists, using the official template. Demo and repo placeholders still incomplete. My Agent Session section empty. Draft edit URL omitted here because unpublished DEV URLs are share-secret.

▸ search_dev_to_semantic query: Hacktoberfest Weekend Challenge DevRelay prize agent session submission

Input

query: Hacktoberfest Weekend Challenge DevRelay prize agent session submission

Output

Official launch post: Join the Hacktoberfest Weekend Challenge: Build for a Friend. Show-your-work: save an agent session with DevRelay and embed it. Cash prizes are overall, Gemma, Backboard, Entire, and other listed partners — not a DevRelay cash prize.

FollowUp in this workspace is branded Recall: a private-first memory assistant for Dad. Local IndexedDB storage, MiniLM embeddings plus lexical retrieval, and Gemma 3 270M in the browser via Transformers.js. Optional Assisted Mode sends retrieved snippets to Backboard. Synthetic demo data is the public judging path.

The live Weekend Challenge matches the product: open-weight local inference for one real person. DevRelay's genuine contribution is the submission workflow, not a new app feature: inspect live rules, confirm there is no DevRelay cash prize, then save and embed an Agent Session so judges can see the process. Closest honest cash categories are Best Use of Gemma and, if Assisted Mode is real, Best Use of Backboard. Entire is a different product.

Recommended next: save a curated Agent Session, Make Public on DEV, patch the existing draft (live demo URL, FollowUp repo, session embed). Do not publish the article until you say so. Do not rewrite FollowUp.

You

Yes. Save the DevRelay Agent Session for this work.

Before submitting it:
1. Curate the session so it clearly shows how DevRelay contributed to preparing my FollowUp Hacktoberfest Weekend Challenge submission.
2. Remove or redact any secrets, API keys, tokens, credentials, private URLs, local machine paths, or other sensitive information.
3. Keep the useful parts: FollowUp inspection, Weekend Challenge verification, DevRelay's role in the submission workflow, and the Agent Session reasoning.
4. Do not modify the FollowUp application code.
5. Submit/save the curated agent session using DevRelay.
6. Give me the resulting session ID or slug and tell me exactly how I make it public on DEV.

Do not publish my Hacktoberfest article yet.

Agent

Curation rules applied before submit:
- Kept: public repo and live demo, challenge dates and judging, DevRelay session workflow, Gemma/Backboard category fit, empty-session finding.
- Redacted: local filesystem paths, MLH user IDs, unpublished draft secret URLs, environment variable values, account identifiers.
- Not included: application code changes. FollowUp was not modified.
- Article remains unpublished.

Submitting this curated transcript to DEV via DevRelay submit_agent_session.

Prize Categories

Best Use of Gemma

FollowUp uses Gemma 3 270M IT as its open-weight language model, running locally through Transformers.js and WASM.

Gemma is part of the core Private Mode architecture rather than being used only as a separate chatbot feature.

Best Use of Backboard

FollowUp also uses Backboard for its optional Assisted Mode.

Backboard provides the hosted RAG path while FollowUp keeps its local/private path separate.

I built FollowUp for one person because one person's annoying everyday problem was enough.

My dad didn't need another chatbot.

He needed to stop asking:

"Where did I get that?"

So I built something that could help him find it and remember what he needed to do about it.

Bringing 3d-blockstack to Life

maitri-vv — Fri, 31 Oct 2025 07:13:25 +0000

🎃 Maintainer Spotlight: Bringing 3d-blockstack to Life

Project: 3D-Blockstack

Hacktoberfest isn't just a month; it's a feeling—especially when you're on the other side of the pull request. For me, the month of October is when my GitHub activity chart goes from 0 to 100, and there's simply nothing more exhilarating. It's a time for finding new tech stacks, squashing bugs, and seeing the open-source community explode with collaborative energy.

My Hacktoberfest journey started back in my college days, thanks to my GDSC chapter. I was instantly hooked on the thrill of contributing and learning. Now, as a maintainer for 3d-blockstack, I get to experience that excitement from a whole new angle.

What is 3d-blockstack and Why I Maintain It

3d-blockstack is an open-source, mesmerizing 3D stacking game built using Three.js for captivating graphics and Cannon.js for realistic physics. It challenges players to build the tallest tower by precisely dropping blocks, featuring responsive design, a high score system, and multiple color themes. I maintain it because it’s a perfect sandbox for developers who want a hands-on experience in game development, 3D rendering, and performance optimization—turning challenging code into a truly addictive user experience.

The best part about being a maintainer is fostering that same spirit of excitement I felt as a first-time contributor. I truly believe that the most valuable contributions often come from fresh eyes. It is surreal to realize that I’m not just leveraging my own skills, but the collective genius of the entire community. Open source embodies the highest form of collaboration, proving that no single person can build a great project alone; like the famous adage, it takes a village of committed contributors to raise a project to its full potential.

✨ How to Contribute to 3d-blockstack

If you're looking for a project that offers real-world impact and a welcoming community, look no further! We've made it easy to jump in:

Read the CONTRIBUTING.md: This is your map! It has all the information about our code style, commit conventions, and setup instructions.
Look for the Labels: We actively label issues with:
- hacktoberfest: General issues suitable for the challenge.
- good first issue: Perfect for beginners or those new to the project.
- enhancement: Ideas for new features or improvements.
Pick an Issue & Comment: Once you find one you like, comment on the issue to let us know you're working on it. This helps prevent multiple people from working on the same thing.
Ask Questions! Don't struggle in silence. If you get stuck, please reach out via GitHub Discussions or Discord. I'm here to help you get that PR merged!

The Hacktoberfest Vibe: A Maintainer's View

As a maintainer during Hacktoberfest, I get to wear a few hats:

The Reviewer: I meticulously check every pull request, focusing on clear communication and constructive feedback.
The Cheerleader: Seeing a contributor, especially a new one, solve a challenging issue or implement a requested feature is incredibly rewarding. I make sure to celebrate every successful merge.
The Vibe Setter: My goal is to make sure every contributor feels welcome, understood, and a valuable part of the 3d-blockstack family. Getting to know that vibe through comments and discussions is what makes the experience so unique and satisfying.

Hacktoberfest transforms the maintenance experience. We get to enhance our project with diverse skills and perspectives, turning good projects into truly great ones.

As Hacktoberfest 2025 draws to a close, the true victory isn't measured just in merged PRs, but in the connections forged and the collaborative energy gained. Serving as a maintainer for 3d-blockstack has been the most rewarding experience, validating the "village" concept of open source collaboration. Thank you to every single contributor who helped us squash a bug, implement a new feature, and make this project truly shine. It is your enthusiasm that powers the open-source world, and I look forward to carrying this spirit alive every year ahead.

May the open source passion keep your charts green and your projects standing tall! Happy Hacking! 🎃

Calling All Contributors: Join the Coffee-Bean Project!

maitri-vv — Tue, 24 Oct 2023 05:59:42 +0000

Introduction

Welcome to the "coffee-bean" project, a delightful open-source project where we brew up the perfect blend of HTML, CSS, and JavaScript. As the project maintainer, I am excited to invite talented developers, designers, and coffee enthusiasts from around the world to join our journey. Whether you're a seasoned coder or just starting your open-source adventure, there's a place for you in our caffeinated world!

What is Coffee-Bean?

"coffee-bean" is an open-source project aimed at creating a beautiful and responsive website for coffee lovers. It's a virtual coffeehouse where we showcase your love for the brew through code and design. With a foundation of HTML, CSS, and JavaScript, we aim to create a dynamic and interactive website that captivates visitors with the aroma and essence of coffee.

Why Contribute?

1. Learning and Growth: As a contributor, you'll have the opportunity to learn and improve your skills in web development. Whether it's refining your HTML structure, perfecting CSS styling, or enhancing your JavaScript interactivity, there's something for everyone.

2. Real-World Experience: "coffee-bean" provides an authentic open-source experience. You'll work on a real project with real users, collaborating with a diverse team of contributors.

3. Portfolio Enhancement: Your contributions will be recognized and credited. This project can be a valuable addition to your portfolio, showcasing your skills to potential employers.

4. A Sense of Community: Join a friendly and inclusive community of developers who share a passion for both coffee and code. We're here to support each other, answer questions, and celebrate successes.

How to Get Started

Explore the Repository: Visit our GitHub repository to get familiar with the project structure, issues, and existing contributions.
Choose an Issue: Browse through the existing issues to find something that piques your interest. We label issues to help you identify tasks suitable for your skills.
Fork the Repository: Click the "Fork" button on the top-right of the repository page to create your own copy of the project.
Make Your Contribution: Work on your chosen issue in your forked repository. Write clean code, test thoroughly, and ensure your changes meet the project's coding standards.
Submit a Pull Request: Once you're satisfied with your contribution, submit a pull request to the main repository. Be sure to include a clear description of your changes.
Collaborate and Communicate: Engage with the community on the issue and pull request threads. Discuss your approach, ask questions, and make improvements based on feedback.

Contributing Guidelines

To maintain a harmonious and productive environment, we've set up some contributing guidelines. Please review our CONTRIBUTING.md for detailed instructions on coding standards, workflow, and expectations.

Conclusion

The "coffee-bean" project is a place where you can indulge in your love for coffee and code simultaneously. It's a fun and educational journey where you can contribute, learn, and grow. Whether you're an experienced developer looking for a new challenge or a newbie eager to take your first steps in open source, we welcome you with open arms.

Together, we can brew something amazing. So, grab your favorite coffee mug, fire up your code editor, and let's create the most aromatic and inviting coffeehouse on the web.

Let's code over coffee. ☕️

Final Thoughts

Thank you for considering joining the "coffee-bean" project. We can't wait to see the creativity, skills, and enthusiasm you bring to our virtual coffeehouse. If you have any questions or need assistance, feel free to reach out. Let's make this project a success, one code commit at a time.

Join the "coffee-bean" community on GitHub today! ☕️

GitHub Repository

Hacktoberfest 2023: Embracing Open Source, Learning, and Gratitude

maitri-vv — Tue, 24 Oct 2023 05:54:57 +0000

Visit hacktoberfest site

Introduction

As the autumn leaves fall and the air gets crisper, the world of open source software enthusiasts comes alive with anticipation. Hacktoberfest, the month-long celebration of open source contributions, has arrived once again, and it's time to reflect on the journey and express our gratitude for this wonderful initiative. In this post, I will share my personal experience with Hacktoberfest, the value it has added to my life, and the lessons I've learned along the way.

The Heartfelt Gratitude

Expressing Appreciation

I would like to begin this post by expressing my heartfelt gratitude towards the Hacktoberfest program. It's more than just a series of events; it's a global community of developers coming together to celebrate open source contributions.

The Spark of Interest

My journey with Hacktoberfest started when I first heard about it. I was curious, but I had never ventured into open source contributions before. The idea of contributing to projects I use every day was fascinating. I decided to give it a try, and little did I know that this decision would transform my perspective on collaborative coding.

Importance of Collective Knowledge

Hacktoberfest isn't just about getting a t-shirt or some cool swag; it's about the collective knowledge-sharing that takes place. It's a unique opportunity to learn and grow as a developer by working alongside some of the brightest minds in the open source community.

Lessons Learned

Lessons from Hacktoberfest

Setting Realistic Goals

One of the key lessons I learned from participating in Hacktoberfest was the importance of setting realistic goals. When I began, I aimed to complete a specific number of pull requests or contribute to a particular project. This approach helped me focus and remain motivated throughout the event.

Documentation and Communication

Another valuable lesson I gained was the significance of documentation and communication. I had to dig deep into project documentation, communicate with maintainers, and even understand issues and features thoroughly. This experience improved my understanding of projects and enhanced my collaboration skills.

The Iterative Learning Process

Hacktoberfest presented its fair share of challenges. I encountered technical hurdles and sometimes struggled to grasp project intricacies. However, each challenge made me a better developer. It taught me patience and persistence in the face of adversity, two qualities that have proven invaluable in my career.

The Joy of Giving Back

The Joy of Giving Back to the Community

Satisfaction in Contribution

There is immense satisfaction in contributing to open source projects. It's heartwarming to know that your work can be used by others and make a real-world impact. The feeling of giving back to the community is beyond words.

Nurturing the Open Source Ecosystem

While it's important to contribute to open source projects during Hacktoberfest, it's equally crucial to maintain and nurture the open source ecosystem. Many projects are the backbone of our work, and supporting them ensures their longevity and growth.

Continuing the Journey

Hacktoberfest is just the beginning. Open source contributions shouldn't be confined to a single month. Encourage others to continue their involvement in the open source community year-round. Become a lifelong contributor, and you'll find that the journey is incredibly rewarding.

Conclusion

Embrace Hacktoberfest and Grow

In conclusion, Hacktoberfest has been an incredible journey of gratitude, learning, and giving back. The experience has been transformative and has allowed me to see the world of open source in a new light.

I encourage all developers, whether beginners or experts, to participate in Hacktoberfest 2023. Let my experiences be an inspiration for your own journey. Here are some practical tips to get you started:

Choose Your Projects Wisely: Select projects that align with your interests and skills.
Set Realistic Goals: Define clear objectives and milestones for your contributions.
Patience and Persistence: Embrace the iterative learning process and don't be discouraged by challenges.
Communication is Key: Reach out to maintainers, ask questions, and seek guidance when needed.
Give Back Year-round: Remember that open source contributions can and should continue beyond Hacktoberfest.

In the spirit of Hacktoberfest, let's embrace open source, celebrate collaboration, and continue to learn and grow as developers. Here's to a bright future of open source contributions, and I invite you to join me on this incredible journey.

APIs 101 with Postman

maitri-vv — Wed, 02 Nov 2022 06:05:33 +0000

Here's a Blog on session : https://medium.com/@maitri.vv/apis-101-with-postman-1a1cfd7acdfe