DEV Community: yashraj jangir

I Know a Spot: Small Discoveries, Open-Weight AI, and a Reason to Go Outside

yashraj jangir — Sat, 10 Oct 2026 09:38:47 +0000

I Know a Spot: Small Discoveries, Open-Weight AI, and a Reason to Go Outside

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

What I Built

Not every reason to go outside needs to be a famous landmark or a carefully planned trip. Sometimes it is a place nearby that you never knew existed: a carved doorway, a patterned wall, a quiet corner, or a small detail someone else noticed.

I Know a Spot is a mobile-first web app for sharing those small discoveries and finding somewhere worth seeing.

The idea is simple: notice → share → discover → go → mark explored.

Get to know your locality better, and when you travel, use the app to discover what other people have noticed.

A contributor takes or chooses a photo, adds a title and personal note, confirms a destination pin, and chooses who can see the spot. An explorer browses those discoveries, searches for what they feel like seeing, opens directions, and gets back to the real world.

There are two discovery feeds:

Connections: spots from you and your configured connections.
Public: spots within your saved discovery radius around an area you explicitly choose.

For this pilot, “Public” means visible to other authenticated, enrolled participants—not anonymous visitors. Public radius is a discovery preference, not a guarantee of privacy: an eligible participant can still open a known Public spot outside their selected radius.

The AI bridges the gap between how someone describes a place and how someone else searches for it. You can search by meaning instead of hoping a contributor used exactly the same keyword.

The app deliberately does not include likes, popularity rankings, public visit counts, or an endless engagement loop. Its main call to action is Open directions. “Explored” is a private, self-reported mark—not a GPS-verified achievement.

Demo

Deployed web app: I Know a Spot

Access note: I Know a Spot currently runs as an authenticated pilot. When a new user signs in with Google, the application automatically creates an enrolled membership for that Supabase Auth account. The backend still checks membership before granting access, and signing in again does not re-enable a disabled membership. There is no anonymous feed. The repository includes setup instructions for running the application with your own configuration.

Suggested walkthrough

Open Discover and switch between Connections and Public.

In Public, choose a discovery center manually or use the explicit current-location button.

Change the saved radius in Profile and return to Public.
Search for a description such as “somewhere tucked away with interesting textures.”

Open a result, read the contributor’s access information, and launch external directions.
Return and mark the spot explored.
Add a new discovery with a photo, note, audience, and destination pin.

I also took the project beyond local code checks. Phone testing, a real outing, searching real notes, and an authenticated walkthrough of the deployed application using Google sign-in were part of the build process. These are qualitative pilot observations, not a measured retention study or a controlled real-world search benchmark.

The frontend and backend are deployed over HTTPS. Deployment checks verified endpoint reachability and CORS, and I completed an authenticated walkthrough using Google sign-in on the final deployment. The deployed flow worked as expected.

Code

yasshhhraj / I-know-a-spot

HackW1TouchGrass

I Know a Spot — application workspace

Mobile-web pilot with a later Capacitor path. See PRD.md, the 36-hour build plan, and future scope.

SETUP.md: manual install/environment/run/check commands.
SUPABASE_SETUP.md: user-run migration, account enrollment and live auth/RLS verification steps.
SPOT_SHARING_SETUP.md: user-run spot/private-Storage migration, backend-only admin configuration and live audience/media checks.
NEXT_FEATURE_PLAN.md: implementation handoff for the Public feed, saved-radius and manual discovery-area slice.
PUBLIC_DISCOVERY_SETUP.md: new Public-feed migration manual area/radius setup and user-run live boundary checks.
SEMANTIC_SEARCH_SETUP.md: MiniLM search, guarded searchable-spot SQL fixtures/cleanup and user-run checks; no new search migration.
SEMANTIC_SEARCH_EVALUATION.md: actual local MiniLM/HTTP synthetic comparison against keywords, with limits.
EXPLORED_SETUP.md: private self-reported explored state, new migration0004 and user-run persistence/authorization checks.
REPORTING_SETUP.md: private predefined reports, new migration0005 and protected local operator review/removal commands and checks.
API_CONTRACT.md: protected profile and spot/media API contract.
frontend/: React/TypeScript/Vite app (port 5173).
backend/…

View on GitHub

Browse the source and setup instructions.

The project is split into a static-buildable frontend and an explicit backend API. Setup guides cover Supabase, sharing, Public discovery, semantic search, explored state, and reporting.

How I Built It

Open-weight AI at the center of discovery

The search model is Xenova/all-MiniLM-L6-v2, an Apache-2.0-licensed model running through Transformers.js in the Node backend.

The inference configuration is deliberately small and explicit:

Quantized q8 CPU inference.
384-dimensional embeddings.
Mean pooling and normalization.
A 256-token input cap.
A pinned model revision with checksum-verified artifacts.

The encoder receives query text and spot titles and notes. It does not receive photos, coordinates, or member IDs as model inputs. Notes can still contain personal information, so minimizing structured inputs does not mean that all text is nonsensitive.

The search flow is:

Authenticated request
  → resolve eligible spots for the selected feed
  → apply Public radius filtering where applicable
  → embed query and eligible title/note text
  → rank by cosine similarity
  → revalidate eligibility and current text
  → return up to three existing spots

Authorization and geographic eligibility happen before ranking. AI is not an access-control layer.

Results show the contributor’s original words. There is no generated claim that a place is safe, open, accessible, or a certain number of minutes away. A low-quality or unavailable search should produce an honest empty or error state, not an invented destination.

For this small pilot, bounded in-memory vectors and direct comparison are enough. I did not add a vector database or a generative chatbot just to make the architecture look more “AI.”

Testing whether semantic search adds anything

I compared the actual cached MiniLM model against a keyword baseline using a 12-query synthetic fixture, with synthetic authentication and candidate data rather than live Supabase records.

Of 11 positive queries, semantic search returned a relevant result in the top three for 11/11, compared with 7/11 for the keyword baseline.
One unrelated negative query returned no semantic matches.

That is useful regression evidence, but it is a small, purpose-built dataset—not proof of general search quality. The similarity cutoff remains provisional for real contributor notes. Real-note search was tried separately without a new quantified comparison.

The rest of the stack

Layer	Technology
Mobile web UI	React, TypeScript, Vite, Tailwind
Maps	Leaflet / React Leaflet
API	Node.js and Fastify
Photo processing	Sharp
Auth, database, protected media	Supabase Auth, Postgres, Storage
Frontend hosting	GitHub Pages
Backend hosting	Docker image in ECR, running on ECS Fargate behind an HTTPS Application Load Balancer

The model artifacts are included in the backend image. Requests never download weights, and inference runs on infrastructure I control rather than a separate hosted model API. This is server-side inference, not on-device or offline inference.

Disclosure: AI assisted with the project and with drafting this article.

What the difficult parts taught me

Mobile lifecycle matters. Returning from the phone camera could trigger a repeated Supabase SIGNED_IN event, causing the verified workspace—and the unfinished form—to remount. The fix ignores only an exact same-user, same-token duplicate event. Token changes, account changes, and explicit access checks still reverify access. This does not solve a browser discarding the entire page.

Visual polish can introduce real regressions. An early UI pass combined conflicting button color classes, leaving white text on a light background. Explicit primary and selected-state styles fixed that. The navigation also moved into a persistent bottom bar after testing made the long Add form’s bottom-only Cancel action inconvenient.

Container size is not model size. The first backend image was about 1.05 GB uncompressed even though its model artifacts were about 23 MB. ONNX runtime dependencies accounted for most of the footprint. I kept the working runtime intact rather than deleting binaries without a tested replacement.

The final runtime image was tested for non-root startup, health checks, actual normalized 384-dimensional embeddings, and Sharp WebP processing. The latest local backend test run passed 139 tests, and the frontend suite passed 67. These checks do not independently validate remote Supabase policies.

Current limits

This is an online-only, bounded pilot—not an unrestricted public platform. New Google Auth users receive an enrolled application membership automatically, while existing memberships are checked by the backend. Connections are configured by the operator, and the app does not yet include in-app connection requests.

Full browser-discard draft recovery is not implemented. Independent checks of all direct Storage and forbidden-write boundaries, exact radius boundaries, and media-erasure behavior remain outstanding. I am keeping those gaps visible rather than treating a successful deployment as a security audit.

Why Does Open Innovation Matter?

For this project, open innovation means being able to choose a small model, understand its role, and run it where it fits the product.

An open-weight encoder made it possible to:

Run inference in the backend container without sending every query and eligible note to a separate model provider.
Pin and verify the model artifacts, making the retrieval setup inspectable and repeatable.
Evaluate semantic ranking against a simple baseline, rather than treating a hosted model’s output as an unexplained recommendation.
Keep model choice replaceable, with explicit evaluation work required if I change models, tokenization, or embedding dimensions.
Avoid per-request model API charges, while still acknowledging that AWS hosting, storage, and networking cost money.

A closed embedding API could also rank text. The difference here is not that closed systems cannot do semantic search; it is that I can distribute and run the model artifacts, control the inference environment, and investigate retrieval behavior without depending on a remote model endpoint.

That control does not make the whole app private or offline. Supabase processes application data, and maps and external directions have their own data flows. It lets me make a narrower, defensible statement about where model inference happens.

The outcome I care about is not a longer AI conversation. It is someone finding one interesting place, closing the app, and going to see it.

My Agent Session

I built with assistance from omnirush.ai across implementation, debugging, UI iteration, testing, and deployment. The camera-return bug and deployment configuration were particularly useful examples of turning a broad symptom into a specific, testable change.

Community references

Two useful perspectives from DEV informed the UI and packaging work:

Designing Mobile-First UX: Responsive Design in Practice, by pipipi-dev: designing around phone constraints and accounting for safe areas.
Multi-stage Docker builds: ship the artifact, not the build shop, by amitshuklabag: separating build tools from runtime artifacts. Our native inference dependencies still required separate size analysis.

Starting my blogging journey with this year’s Hacktoberfest. #HF26 I’ll be sharing what I learn, build, break, and figure out along the way. A lot more coming soon — follow along and learn with me!

yashraj jangir — Mon, 05 Oct 2026 07:46:06 +0000

Hacktoberfest Weekend Challenge: Build for a Friend Submission 🤝

yashraj jangir

Oct 5

Focus Agent: A Local AI Focus Companion Built for a Friend

#hf26challenge #gemma #linux #productivity

5 min read

Focus Agent: A Local AI Focus Companion Built for a Friend

yashraj jangir — Mon, 05 Oct 2026 06:51:21 +0000

Focus Agent: A Local AI Focus Companion Built for a Friend

This is my submission for the Hacktoberfest Weekend Challenge: Build for a Friend, including the Best Use of Gemma category.

Project: Focus Agent on GitHub

Demo: Watch the captioned walkthrough

The idea: help Raj return to his own priorities

Raj is a friend who is talented and ambitious, but can get pulled into interesting side quests and lose track of the task he meant to finish. A to-do list can remember the plan. A screen-time chart can count applications. Neither can connect the two in a way that gives him a useful, timely nudge.

So I built Focus Agent: a desktop companion that lets Raj state his priorities, observes which application is active, and checks whether that activity seems connected to the current task. If the relationship is unclear, a local Gemma model helps interpret a small, allowlisted context. If distraction remains likely and Raj ignores the check-in, the intervention becomes more visible. Raj can correct the classification, switch tasks, take a break, or pause monitoring.

The agent is meant to help someone act on their own intentions, not to judge their productivity. It explains its reasoning and leaves the decision with Raj.

What works today

Turn a natural-language plan into a short list of tasks and set the current priority.
Track application changes through a small KDE KWin script and local D-Bus bridge.
Save activity sessions, tasks, corrections, breaks, and intervention responses in local SQLite.
Use Gemma through Ollama for ambiguous activity, with strict JSON validation and deterministic policy checks.
Remember Raj's “still related” corrections for a task and application.
Escalate ignored drift prompts from a quiet notification to a full-window intervention.
Pause monitoring for 15 or 30 minutes, 1, 2, or 4 hours, or until Raj resumes it.
Keep planning usable with a deterministic fallback if Ollama or Gemma is unavailable.

Gemma matters to the core loop: application names alone do not tell us whether a window is useful for the task. Running the model locally means activity context does not need to go to a hosted inference service. The project is open source, so the collection and decision flow can be inspected.

Development environment

This prototype currently targets Linux with KDE Plasma 6 on Wayland. To run it, you need:

Node.js 22 or newer and npm;
KDE's KWin script and D-Bus support;
Ollama with a Gemma-family model (the README uses gemma3:1b as a small starting point).

After installing dependencies, the repo documents npm test and npm run dev, plus commands to install the KWin activity bridge. The model download is needed for local reasoning; once the model and dependencies are installed, inference does not need a hosted AI API.

This is a Linux prototype, not a cross-platform release. The activity bridge is KDE-specific, and I have not yet validated it on X11, Windows, or macOS.

What I saw while testing

In one short real desktop session, Firefox, VS Code, and ChatGPT were classified as related to the active task. I then used Chrome for about ten minutes; Focus Agent left it as unknown. That conservative result is useful: an unfamiliar browser should not automatically be called a distraction just because it is a browser. It also showed me a current limitation: without browser-domain or page context, application-level signals can be too coarse to tell what someone is doing.

I also exercised the reasoning path with gemma3:1b: an obvious game launcher produced a high-confidence distraction result, while an unknown browser stayed low-confidence/unknown. These are prototype checks, not a broad accuracy study. More testing with Raj and other users is still needed.

The demo includes representative preview data for the full intervention sequence. Waiting through real cooldowns made it impractical to capture every escalation level in a short walkthrough, so I used preview data for that part rather than implying the video is a continuous live session.

Setbacks that changed the design

One UI bug taught me that activity tracking and interface actions can interfere with each other. When I clicked Still related, Focus Agent itself became the active window before the correction landed, so the action could apply to the wrong activity. I changed the flow to preserve the intended activity target and filter Focus Agent's own window from collected activity.

Another challenge was deciding what an application name can really prove. My Chrome observation remained unknown, and that is preferable to inventing certainty. The bridge currently sees application-level context, not browser URLs, page contents, or documents. I kept that boundary explicit and made corrections available to the user.

I also started after missing the first few days of the challenge, so the scope had to stay focused: a working Linux prototype, a clear demo, and a privacy model I could explain rather than a premature promise of support for every desktop.

What comes next

I want to finish this as a dependable cross-platform project. The next work is to add activity adapters for other Linux desktop environments and X11, then build and test native activity integrations for Windows and macOS. I also want to test with Raj, improve the app-level ambiguity handling without collecting more personal data than necessary, and make packaging and first-run setup easier.

If you work on desktop integrations, local AI, privacy-respecting productivity tools, or testing across Linux setups, contributions and issue reports are welcome. Please open an issue or pull request on the GitHub repository; small, well-scoped contributions are especially helpful.

KDE Wayland release candidate

The Focus Agent v0.1.0-rc.1 GitHub release is available for KDE Plasma 6 on Wayland, x86_64. The AppImage bundles Electron and its Node.js runtime, so you do not need to install Node.js separately. Ollama with Gemma is still needed for local reasoning, and the KWin activity bridge is available as a separate download on the release page. The README includes setup steps. This is an unsigned release candidate built on Kali Linux Rolling; it has not been validated on other distributions.

DEV Community: yashraj jangir

I Know a Spot: Small Discoveries, Open-Weight AI, and a Reason to Go Outside

I Know a Spot: Small Discoveries, Open-Weight AI, and a Reason to Go Outside

What I Built

Demo

Suggested walkthrough

Code

yasshhhraj / I-know-a-spot

HackW1TouchGrass

I Know a Spot — application workspace

How I Built It

Open-weight AI at the center of discovery

Testing whether semantic search adds anything

The rest of the stack

What the difficult parts taught me

Current limits

Why Does Open Innovation Matter?

My Agent Session

Community references

Starting my blogging journey with this year’s Hacktoberfest. #HF26 I’ll be sharing what I learn, build, break, and figure out along the way. A lot more coming soon — follow along and learn with me!

Focus Agent: A Local AI Focus Companion Built for a Friend

Focus Agent: A Local AI Focus Companion Built for a Friend

Focus Agent: A Local AI Focus Companion Built for a Friend

The idea: help Raj return to his own priorities

What works today

Development environment

What I saw while testing

Setbacks that changed the design

What comes next

KDE Wayland release candidate

Related reading from DEV