DEV Community: Soham Maity

Moss: A Local-First Assistant That Grows on You While You Sleep 🦥

Soham Maity — Sun, 25 Oct 2026 07:30:54 +0000

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

What I Built

Moss is a local-first assistant that does the chores you put off — while you sleep. It runs entirely on your own machine using open-weight models (via Ollama), and leaves a single Morning Brief each day summarizing what it did.

Three "sloth" skills, one CLI:

moss tidy ~/Downloads — sort, rename, archive clutter (dry-run by default)
moss digest whatsapp.txt — two-line summary, who you owe, dates, ignore verdict
moss fridge fridge.jpg — grocery list from a fridge photo
moss nap — run everything configured overnight, write the Morning Brief
moss undo — restore the last tidy run exactly, byte for byte

The Morning Brief is a single self-contained HTML file (inline CSS, inline SVG sloth, no JS, no CDN) plus a Markdown twin. It works offline, is dark-mode ready, and mobile-friendly.

Example output:

$ moss nap --demo --paranoid
Morning. Moss finished while you slept.
Brief: /home/soham/Moss/morning/2026-10-23.html
       /home/soham/Moss/morning/2026-10-23.md
Cloud API cost: $0.00
Paranoid proof: 0 outbound connections attempted. Model ran on localhost only.

Demo

Moss is local-first by design, so there's nothing to deploy — it runs on your laptop. Try the full pipeline with no model installed:

pip install -e .
ollama pull qwen3:4b
cp moss.example.yaml ~/Moss/moss.yaml
# edit ~/Moss/moss.yaml to taste
moss nap --demo --paranoid

The --demo flag uses a mock backend, so no model download is required. Add --paranoid to prove zero outbound connections.

Code

Moss is MIT-licensed, written in Python 3.11+, and structured around a backend-agnostic LLM interface (BaseBackend with generate and generate_json) so you can swap Ollama, llama.cpp/LM Studio, or a deterministic mock in one line.

Install and run:

pip install -e .
moss nap --demo --paranoid

Skills live in src/moss/skills/ (tidy, digest, fridge), extraction in src/moss/extract/ (PDF, DOCX, mbox, WhatsApp, Telegram, plain text), and storage is SQLite with an append-only undo journal for byte-for-byte restoration.

SpreadSheets600 / Moss

Moss

Does the work while you hang around.

A local-first assistant that grows on you while you sleep. Built for the "Slow and Steady" theme (International Sloth Day): open-weight models at its core, runs entirely on your own machine, and rewards laziness by doing the chores you put off.

What it does (15 seconds)

Moss runs overnight and leaves a single Morning Brief (~/Moss/morning/YYYY-MM-DD.html + a .md twin). It has three sloths ("skills"), one CLI:

$ moss tidy ~/Downloads          # sort, rename, archive clutter (dry-run by default)
$ moss digest whatsapp.txt        # two-line summary, owes, dates, ignore verdict
$ moss fridge fridge.jpg          # grocery list from a fridge photo
$ moss nap                        # run everything configured, write the Morning Brief
$ moss undo                       # restore the last tidy run exactly

Example terminal transcript:

$ moss nap --demo --paranoid
Morning. Moss finished while you slept
Brief: /home/soham/Moss/morning/2026-10-23.html
       /home/soham/Moss/morning/2026-10-23.md
Cloud API

…

View on GitHub

How I Built It

Moss is built around open-weight models running locally, not closed cloud APIs.

Backend: Ollama (localhost:11434) with qwen3:4b for text tasks (tidy, digest) and qwen2.5vl:7b for vision (fridge photo). Verified end-to-end with gemma4:31b-cloud (32.7B on CPU) via Ollama.
Backend abstraction: A common BaseBackend interface keeps skills backend-agnostic. A MockBackend powers --demo mode, so the full pipeline runs with no model installed — essential for hackathon sandboxes without Ollama.
Stack: Python 3.11, Typer (CLI), Rich (terminal output), Pydantic v2 (config), PyYAML, psutil (battery/idle detection), pypdf + python-docx + Pillow (extraction), Jinja2 (brief HTML), httpx (Ollama client), SQLite (cache + undo journal), pytest + ruff.
Paranoid mode: --paranoid monkeypatches socket.socket so any non-loopback connection raises OfflineError. Proof: 0 outbound connections — nothing phones home.
Slow and steady: Runs at nice -n 19, skips runs on battery below 40%, caches decisions by content hash so nothing repeats, and schedules at 2:00 AM by default.

Why Does Open Innovation Matter?

Open innovation made Moss possible in ways a closed API never could:

Airplane mode works. moss paranoid proves 0 outbound connections. Your model runs on localhost; nothing leaves the machine.
Your data stays put. Downloads, WhatsApp exports, email, fridge photos — all processed locally. No uploads to third-party servers.
Zero cost. Cloud API cost: $0.00. No subscription, no per-call fees, no model deprecation risk.
You own the behavior. Swap models with moss use gemma3:4b. Edit prompts and config in moss.yaml. Hosted assistants don't let you do this.

A hosted assistant would need your personal chats and file contents sent to a third party, wouldn't work without internet, would charge recurring fees for a nightly job, and could deprecate the model you depend on overnight. Moss avoids all of that.

My Agent Session

The Lazy Payoff

Moss saves you from the chores you keep postponing: sorting a messy Downloads folder, summarizing long WhatsApp threads, checking what's missing from the fridge. It runs overnight at low priority (nice -n 19), so you wake up to a done list instead of a to-do list. The undo journal means you can restore any tidy run byte-for-byte if you change your mind.

Prize Categories

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

tags - #devchallenge #hacktoberfest #ai #opensource #python

WildQuest: Offline Nature Quests with On-Device Qwen AI

Soham Maity — Sat, 10 Oct 2026 07:43:02 +0000

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

What I Built

WildQuest is a mobile-only, offline-first nature exploration game. You pick a 15-, 30-, or 60-minute walk and a theme (plants, birds, textures, general nature), and the app generates 3–5 short missions from an on-device open-weight LLM — with a bundled curated mission library as fallback, so it works with zero connectivity.

The point is the screen stays secondary: you read one mission, put the phone away, and go outside. When you come back you photograph what you found, describe it in a sentence or two, and the same on-device model structures it into an ID suggestion (label, confidence, key features). Everything — quests, photos, notes, AI text — lives in on-device SQLite, including half-typed drafts that survive app restarts. The walk ends with a field journal: completions, observations grouped per mission, and questions for the next walk.

It is for anyone who walks past nature without noticing it: beginners who want structure, parents, run-club regulars who want a reason to look up.

Demo

There is no deployed link — it is a native Android app, not a website. Install the release APK (arm64, 128 MB) directly:

adb install -r app/build/app/outputs/flutter-apk/app-release.apk

Offline proof you can repeat: turn on airplane mode, generate a 15-minute plants quest (it arrives with a "Curated" chip), complete a mission, save a note, kill the app, reopen — quest, drafts, and history are intact. With the model downloaded once (~1 GB, Settings tab), the same flow runs fully offline with the chip reading "On-device AI". A field-test video is still TODO before the deadline.

Code

https://github.com/SpreadSheets600/WildQuest

Note: the code push is in flight (local commits verified, remote push pending) — the repo will hold the full history: Flutter app, Python dev backend, docs with architecture diagrams.

How I Built It

The open-source AI is the core, in three places:

Quest generation — Qwen2.5-1.5B-Instruct Q4_K_M (official Qwen GGUF on Hugging Face, ungated, Apache-2.0), run on-device through llamadart 0.11 (llama.cpp), CPU, 2048 context. The prompt demands strict JSON (missions with time, difficulty, safety notes); every output is re-validated by a rules engine (timebox fit, difficulty cap, banned-phrase safety check with negation handling). Any failure falls back to the curated library — and the UI chip always names the true source.
Photo suggestions — the same Qwen model, describe-then-structure: no vision model on purpose (multimodal GGUFs are ~2 GB+ and experimental on low-end phones). You describe what you saw; the model returns structured JSON offline. Without a model the box honestly says "No model — not AI".
Why this model: an earlier build used Gemma 3n + MediaPipe and thrashed on real phones. Q4_K_M is the community-default quant (~1% perplexity cost), ~1 GB weights with a small KV cache — the phone bottleneck is memory, not speed, so the app runs CPU with a short context.

No server, no account, no API keys. A Python/FastAPI + Ollama backend exists in the repo purely as a dev reference with the same prompt shapes and rules.

Why Does Open Innovation Matter?

Four things a closed API could not do here:

Airplane-mode nature walks. A birding trail with no signal is the whole use case — a cloud API makes the app a brick exactly where it matters.
Location privacy by construction. Photos, notes, and implicitly where-you-walked never leave the device. There is no server to trust.
Swappable, inspectable behavior. The model URL is a setting, not a vendor lock-in — the rules engine, prompts, and validation are all in the repo to read and change.
Zero marginal cost. A free app for beginners cannot pay per-token for every quest and every photo description.

My Agent Session

Session transcript available on request — happy to embed it via DevRelay before the deadline.

Prize Categories

None — the build uses no partner technology (the earlier Gemma integration was removed for on-device performance reasons). Entering for the overall prize only.

Recall: A Local-First AI Memory for Everything You’ve Saved

Soham Maity — Sun, 04 Oct 2026 18:38:17 +0000

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

What I Built

I built Recall, a local-first personal memory system for a friend who has a habit of saving everything: screenshots, useful webpages, PDFs, notes, images, and random files that might be useful someday.

The problem was not storing those things. It was finding them again.

A normal keyword search works when you remember the exact words. But memory usually does not work that way. You remember “that screenshot about the GitHub DNS problem”, “the article about FAISS”, or “the image with the terminal error”. You remember the idea, not necessarily the exact filename or sentence.

Recall turns those scattered files into searchable memories.

You can ingest text, webpages, images, screenshots, PDFs, and other files, then search the collection using natural language. Images are processed with OCR and image captioning so that the information inside them can become searchable too.

For example, instead of remembering a filename, you can search:

“the screenshot where GitHub could not resolve the host”

and retrieve the relevant memory.

The important part is that this is local-first. The data stays on the machine, there are no accounts or cloud APIs required, and once a memory has been processed, searching does not need a generative AI model running in the background.

Demo

https://youtu.be/1NzE_2FwT_U

Code

Recall on GitHub

The repository is open source and contains the backend, frontend, ingestion pipeline, search system, tests, and technical documentation.

How I Built It

The core idea was to use AI where it provides the most value, rather than making an LLM responsible for every query.

Recall processes content during ingestion:

content
   ↓
metadata + content extraction
   ↓
OCR / image captioning
   ↓
searchable text
   ↓
embeddings
   ↓
SQLite + FTS5 + FAISS

For image understanding, Recall uses BLIP-base for image captioning and RapidOCR for OCR. For semantic retrieval, the default embedding model is Google's EmbeddingGemma 300M, with automatic fallbacks to all-MiniLM-L6-v2 and finally deterministic hash vectors when model availability is limited.

The backend is built with FastAPI and Python. Memories are stored in SQLite, with SQLite FTS5 providing BM25 lexical search and FAISS providing vector retrieval.

The final search is hybrid:

BM25 search ─────┐
                 ├── Reciprocal Rank Fusion ──→ ranking
Vector search ───┘
                       + metadata
                       + recency
                       + exact-match signals

This solves a practical problem with relying on embeddings alone.

Semantic search is good at understanding that “DNS failure” and “could not resolve host” may refer to the same thing, while lexical search is much better at exact strings such as error messages, filenames, or identifiers.

AI therefore does the expensive work once at ingestion, and retrieval stays deterministic and fast.

The frontend is built with React and Vite, with the production build served by the FastAPI application.

I also designed the system around a few constraints that mattered for this project:

The database is the source of truth; the FAISS index can always be rebuilt.
Ingestion is idempotent, using content hashes to avoid processing the same file repeatedly.
AI failures should not make the entire ingestion pipeline fail.
Search should continue working even when the optional AI models are unavailable.
The application should be usable on a normal laptop rather than requiring a dedicated GPU.

Why Does Open Innovation Matter?

For this project, open innovation is not just about avoiding an API bill.

Memory is personal.

A system that is indexing screenshots, documents, saved pages, and private notes should not require sending that collection to a remote service just to make it searchable.

Open models made it possible to build the important parts of Recall locally: image captioning, OCR, and semantic embeddings can all happen on the user's machine.

That changes the trade-off completely.

Instead of:

“Upload my personal data to a service so an AI can understand it.”

the model becomes:

“Let the AI understand my data locally, store the useful representations, and search them without an online AI dependency.”

It also makes the system easier to experiment with. Models can be swapped, compared, or removed without redesigning the entire application around one proprietary API.

For a personal memory system, that control is as important as the model quality itself.

Prize Categories

Google Gemma

Recall uses Google's EmbeddingGemma 300M as its primary semantic embedding model.

EmbeddingGemma converts memories into vector representations that allow Recall to retrieve content based on meaning rather than exact keywords. This is particularly important for personal memories because users often remember the context of something without remembering the exact words contained in it.

For example, a user can search for:

“the screenshot where GitHub couldn't resolve the host”

even if the original screenshot contains an error such as:

“fatal: unable to access... Could not resolve host: github.com”

EmbeddingGemma provides the semantic layer that makes this kind of retrieval possible.

The model runs locally, so the user's personal memories do not need to be sent to a remote embedding API. Recall stores the generated embeddings locally and uses FAISS for vector retrieval.

I chose EmbeddingGemma because it provides a strong semantic representation while remaining practical for a local-first application. It also supports longer input than the lightweight embedding models I initially considered, which is useful when memories contain documents or substantial extracted text.