Strikethrough

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

What I Built

I built Strikethrough for a friend while we were planning a group trip through WhatsApp.

As the chat grew, plans kept changing, the times, places, bookings etc, while all the old messages stayed there. At some point, figuring out the latest plan meant scrolling through a wall of messages and asking:

“Wait, what did we finally decide?”

That was the problem I wanted to solve.

Strikethrough treats a group chat like a document with revision history.

Paste the conversation and it identifies information that was later changed, cancelled, corrected, or replaced. Those messages are crossed out, while the information that survived becomes the Current Reality.

Every current fact links back to the message that established it, so you can check the source instead of trusting a generated summary.

The idea is simple:

Group chats have version history, but no version control.

Demo

Live: https://strikethrough.onrender.com

The app opens with a sample conversation ready to resolve.

Press Resolve to watch outdated messages get crossed out and the latest confirmed information collected into Current Reality.

You can also paste your own conversation.

Code

GitHub: https://github.com/BigBang001/Strikethrough

The project is intentionally small: a single-page frontend and a lightweight Node.js server.

How I Built It

The core reasoning is handled by Gemma.

I didn't use the model to generate another chat summary. I gave it a more specific job: understand how facts change across a conversation.

For each message, Gemma determines whether it is:

• live — still current
• superseded — later information replaced it
• noise — not part of the changing state

For superseded messages, it identifies the later message that replaced them. It also extracts the current facts and the source message for each one.

For example:

“Dinner is at 8.”

followed later by:

“Actually, make it 9.”

The interesting task is not to repeat both messages. It is to understand that 8 PM is now obsolete and 9 PM is the current value.

The server validates Gemma's structured output before rendering it, including checking source-message references and handling malformed responses.

The interface makes that reasoning visible. Instead of hiding the result in a paragraph, outdated messages are crossed out with a red proofreader-style mark, and the surviving information becomes the current state.

The implementation is deliberately lightweight: plain HTML, CSS and JavaScript with a small zero-dependency Node.js server. There is no database, authentication, or unnecessary backend infrastructure.

The built-in example also uses a cached result, so the main product experience remains available even without a model request. Custom conversations are resolved through Gemma.

Why Does Open Innovation Matter?

Group chats can contain private plans, addresses, schedules, family information, and other personal details.

An open-weight model gives this kind of tool an important option: it can be self-hosted and controlled, rather than requiring personal conversations to always be processed by a proprietary model.

The reasoning model can also be swapped, adapted, or fine-tuned without redesigning the product around one closed provider.

For this submission, the deployed version uses a hosted Gemma endpoint through Google AI Studio. I am being explicit about that rather than calling the deployment local.

What matters is that Gemma is doing the core reasoning: deciding which information in a conversation survived later changes and which became obsolete.

Prize Categories

Gemma — Gemma powers the core conversation reasoning and supersession detection.

Render — Render hosts the public web application and its backend endpoint.