DEV Community

Tanisha Naruka
Tanisha Naruka

Posted on

Hammock Report

Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady Submission 🦥

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

What I Built

You come back from a week offline and your group chat has 1,400 unread messages. Most of it is memes. Somewhere inside is the one question that was waiting for you.

Hammock Report reads an exported WhatsApp chat and sorts every conversation into three piles:

  • Needs you: you were asked directly, or a decision is still waiting on you.
  • Already resolved: someone raised it and a later message settled it.
  • Safe to ignore: banter and small talk that asked nothing of you.

Every verdict comes with a one-line reason, so you can check the model instead of trusting it. The report also shows the reading time you save, a timeline of the conversations, and who talked most. You can move any conversation to a different pile and download the result as Markdown.

The lazy part: you export the chat, press one button, and read only the pile that needs you.

It comes in two forms: a single-file web app with a mission-control look (radar scan, gauge, star map), and a Python command-line script that uses only the standard library.

Demo

https://drive.google.com/file/d/1sod2JuwYfVdYHk55ZsIpvuCXw8vjdA5u/view?usp=sharing

Code

https://github.com/tanisha-naruka/Hammock-Report.git

How I Built It

The open-source AI is Ollama running Qwen2.5 3B on the user's own machine. The model name is one setting, so you can swap in Llama 3.2 3B or Gemma.

A 3B model reads a short conversation far better than a week of chat, so the app:

  1. Parses the WhatsApp export (Android and iPhone formats), skipping system lines and media placeholders.
  2. Splits the messages into conversations wherever there is a quiet gap, 30 minutes by default.
  3. Asks the model, for each conversation, three yes/no questions plus a one-line summary and reason. It uses Ollama's JSON mode at temperature 0, so the same chat gives the same answers.
  4. Sorts the answers: Needs you wins first. Otherwise a raised-and-resolved conversation is Resolved, and the rest is Safe to ignore.

The prompt, sent for every conversation:

You triage a group chat for {name}, who was away. Read this conversation.
Reply with JSON only, with keys:
"request_raised": true/false (was a question, request or decision raised?)
"resolved": true/false (was it answered or settled later in this same conversation?)
"needs_me": true/false (does it still need {name} to act or decide, or was {name} directly asked?)
"summary": one short sentence
"reason": one short sentence explaining the verdict
Enter fullscreen mode Exit fullscreen mode

Small models are unreliable, so I added some safety nets:

  • If a model call fails, the conversation is filed under Needs you, so a failure never hides something.
  • Small models sometimes answer "false" as text instead of a real boolean. The code reads both correctly, and I have a test for it.
  • Very long conversations are trimmed to their start and end so they fit the model.

The web app is one HTML file with vanilla JavaScript and no build step.

Why Does Open Innovation Matter?

A group chat is not only my data. It holds my friends' messages too, and they never agreed to have them sent to a cloud API. Running an open-weight model locally means the whole chat stays on my machine, which a closed API could not offer.

  • Private: nothing is uploaded.
  • Offline: it works on a train once the model is downloaded.
  • Free at any size: a bigger backlog costs time, not money, so I never have to think about per-message cost.
  • Swappable: --model lets me try another model on the same chat and compare.

Where a closed model would likely be more accurate, I say so plainly in the next section. For this job, privacy mattered more to me than the last few points of accuracy.

The Lazy Payoff

[Run it on a real chat export and fill this in with real numbers: messages, conversations, how many needed you, how long the run took, and how many mistakes you found when you spot-checked the Safe to ignore pile. If you can't, delete this section.]

Honest limits

  • A 3B model can miss a request buried in a long thread. That is why every verdict shows its reason.
  • Dry run mode is only a keyword check for testing the page. Do not judge accuracy from it.
  • The "minutes saved" figure assumes about 5 seconds per message, so it is an estimate.
  • The numbers on the home page (1,400 messages, 11 that need you) are example figures. The report screen shows real counts.

Top comments (0)