DEV Community: NIKITHA S

Receipts,Not Rumors

NIKITHA S — Sun, 25 Oct 2026 19:22:41 +0000

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

What I Built

Receipts, Not Rumors is a research workspace for when the internet is arguing about something and you just want to know what's actually sourced.

You dump in the mess: screenshots, copied posts, links, your own notes. It turns that into an organized evidence trail:

Screenshots are read with OCR, so the text inside is searchable.
Links are fetched and their content is pulled in.
A local AI model builds a chronological timeline, flags what is direct evidence vs. a reported claim vs. someone's interpretation, and lists what remains unknown.
A visual timeline shows each event as a dot on a horizontal line. Hover for a one-line summary and confidence level, click to jump to the source it came from.

The AI is told to never invent dates, quotes, or URLs, to treat search snippets as leads rather than proof, and to avoid inferring private relationships from ambiguous posts. Its "bottom line" is deliberately cautious.

Who gets to be lazier? Anyone who has spent an evening with 40 tabs and a pile of screenshots trying to work out "wait, who posted first?"

Demo

There's also a Try demo button that loads a clearly fictional scenario, so you can see the whole flow without using real people's posts.

Code

[GitHub repo here:

stargalax / receipts-not-rumors-web

Receipts, Not Rumors

Drop the mess. Get the evidence trail.

A local-first research workspace for when the internet is arguing and you just want to know what's actually sourced. Paste screenshots, links, copied posts, and notes, and it organizes them into a sourced, chronological timeline, with the uncertainty left in.

Features

Screenshot OCR: text inside images is extracted in the browser with Tesseract.js.
Link fetching: pasted URLs are fetched server-side and their readable text and publish date are extracted.
Web search: the model writes up to three search queries, and SerpAPI returns public results as extra sources.
AI timeline: a local Qwen model separates direct evidence, reported claims, and interpretations, and lists what remains unknown.
Visual timeline: events appear as dots on a horizontal line. Color shows confidence, hover shows a one-line summary, and click opens the source.
Guardrails: the model must not invent…

View on GitHub

]

How I Built It

Qwen2.5-1.5B-Instruct (open weights) runs entirely in the browser through WebLLM and WebGPU. No inference server and no API bill.
Tesseract.js does OCR on screenshots, also in the browser.
React + Vite for the frontend.
A small Express backend with two jobs:
- /api/search calls SerpAPI. Qwen first writes up to three search queries from the evidence, and the backend runs them so the API key never reaches the browser.
- /api/fetch-page fetches pasted links and extracts readable text with Cheerio. A browser can't do this itself because of CORS. It refuses private/local addresses and checks every redirect.

The flow is: collect evidence, let Qwen plan searches, add the public results as new sources, then have Qwen build the timeline using only the supplied source IDs. After the model replies, the code validates its output. Any source ID the model made up is stripped or labeled "Unknown source", so the model can't cite something that doesn't exist.

Search results are tagged as unverified snippets, and a page that failed to load says so on its source card instead of quietly counting as evidence.

Why Does Open Innovation Matter?

This tool handles screenshots of people's posts and half-formed theories about them. Sending all of that to a closed API felt wrong, so the analysis stays on the user's machine. The evidence and the reasoning never leave the browser. Only the short search queries and pasted links go through my backend.

Open weights made that possible. A small open model that runs locally through WebLLM means no per-request cost, no usage logs on someone else's server, and nothing that disappears if an API changes its terms. The tradeoff is real: a 1.5B model is small, so it sometimes leaves dates empty or writes generic explanations. I handled that by validating its output and falling back to dates from the sources themselves. For this use case, a modest model I can trust with private material beats a stronger one I can't.

(Honest note: web search still uses SerpAPI, which isn't open. That's the one closed piece, and it's easy to swap for a self-hosted search option.)

Partner Category used

- Best Use of SerpApi : I used SerpApi to help the model get more insights regarding the question asked by allowing it to surf the web

QueueInk

NIKITHA S — Mon, 19 Oct 2026 05:06:29 +0000

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

What I Built

A tattoo inquiry usually shows up as a vague DM: "small fox on my forearm, kinda fine line, budget around 400Rs, need it before the 20th." Size, references and exact placement are often missing, and some requests are things the artist simply doesn't do. Answering every one by hand takes time, and so does saying no.

QueueInk is an inquiry desk for solo tattoo artists. The artist sets their own rules once: styles they don't do, placements they avoid, a minimum price, and whether they take cover-ups. Then they paste an inquiry and get:

Flags from their own rules. These are checked by plain code, not by the AI.
An editable job card with subject, style, placement, size, colors, references, budget and timing, in the client's own words.
A draft reply. If a hard rule is hit, it's a polite decline built from the artist's rules, and the AI isn't even called. Otherwise it asks only for what's missing.
A private queue with statuses (Inquiry, Quoted, Deposit requested, Booked, and so on), notes, JSON backup and a delete-everything button.

The AI never accepts a job, never sets a price and never creates artwork. It only reads text and drafts a message that the artist edits.

Who would pay?
I think solo artists who book through DMs could, since it saves repetitive replies. I haven't tested whether they'd pay.

Demo

Deployed link : https://huggingface.co/spaces/nikisded/queueInk

Sample video: [Link to your video, if you made one]

The sample message on the demo is made up. Please don't paste real client messages into the hosted version (see "Why Does Open Innovation Matter?").

Code

stargalax / QueueInk

title: queueInk emoji: /'o-o'
sdk: gradio sdk_version: 5.50.0 app_file: app.py pinned: false

View on GitHub

How I Built It

Model: [Qwen2.5-0.5B-Instruct / 1.5B-Instruct], an open-weight model, run with Hugging Face Transformers. I first tried Gemma, but it was too slow on my setup, so I switched to Qwen.
App: Python and Gradio. Saved commissions and rules live in the browser's localStorage, not on a server.
Hosting: a Hugging Face Space on ZeroGPU.

The design choice that mattered most: the model has a narrow job. Budget parsing, flags, "what's missing" and the decline decision are ordinary code driven by the artist's settings. The model only extracts a few fields and writes a friendly reply. That keeps decisions predictable, makes declines instant (no model call), and means a small model is enough.

A few details I'm happy with:

Client text is treated as untrusted. It can't change the model's instructions or the output format.
If the model returns something unreadable, the app falls back to a basic reply instead of crashing.
Health or age mentions are flagged as a prompt for the artist to ask the client, and the tool gives no medical advice.

Performance, honestly: my first run on my local space took 90.8s. But after having it hosted on HuggingSpace with ZeroGPU that time came to be 3.7s

What it can't do: the rules use keyword matching, so unusual wording can slip through and some phrases false-alarm. A small model gets fields wrong sometimes, which is why every field is editable. I tested it on 10 inquiries, not at scale.

Why Does Open Innovation Matter?

Tattoo clients send personal details, and sometimes health or age information. Because the model is open-weight, an artist can run QueueInk entirely on their own computer:

pip install -r requirements.txt
python app.py

After the first model download, nothing needs to leave the machine, there's no per-message API bill, and nobody can change the price or switch the model off. Because the weights are open, the model can also be swapped or tuned later for how artists actually write.

I want to be clear about the limits:

The hosted demo is not private. On the Space, pasted text is processed on Hugging Face's server, so use made-up messages there. Running locally is the private way to use it.
Saved data isn't encrypted. The queue is stored in the browser, so anyone with access to that browser profile could read it.
A small model makes mistakes. That's why the rules, not the model, decide, and why the artist reviews every draft.

Prize Categories

Overall

Check out my submission for the #Hacktoberfest conducted by MLH x Dev community! Would love to hear your thoughts on this.Thank you

NIKITHA S — Mon, 05 Oct 2026 07:14:29 +0000

NIKITHA S

Oct 5

GetOut!

#devchallenge #weekendchallenge #hf26challenge

5 min read

GetOut!

NIKITHA S — Mon, 05 Oct 2026 06:40:42 +0000

🚶 GetOut! — Draw Your Route, Not Just Your Steps

What I Built

GetOut! is a multiplayer walking/cycling game that turns a simple outdoor activity into a challenge.

The idea came from a very simple problem:

Sometimes you want to go outside with a friend, but you don't really know what to do once you're out there.

Instead of just tracking steps or following a predefined route, GetOut! gives both players a shape to complete.

One player creates a session and shares a short join code with their friend. Once both players join, the game generates a challenge such as a triangle, square, or other geometric shape.

Each player gets the same challenge, but it is anchored around their own starting location.

The actual walking route is generated using real-world roads, so the challenge becomes:

Start → Checkpoint A → Checkpoint B → ... → Finish

Players can see their progress, reach checkpoints, check in, and try to complete the challenge as quickly as possible.

The goal isn't to create the perfect geometric line on a map.

It's to turn:

"Let's go for a walk."

into:

"Let's see who can complete the triangle first." 🏃‍♀️

Demo

🌐 Live Demo:
https://get-out-nine.vercel.app/

The frontend is deployed on Vercel, while the multiplayer FastAPI backend runs on Render.

How to try it

Open GetOut!
Create a session.
Share the generated 6-character code with a friend.
Your friend joins using the code.
Start the challenge.
Follow the generated checkpoints.
Complete the shape and compare your time!

Code

GitHub:
https://github.com/stargalax/GetOut

The project is split into:

React + Vite frontend
FastAPI multiplayer backend
Qwen3 running locally in the browser
Valhalla / OpenStreetMap for road routing
WebSockets for real-time player communication

How I Built It

The most important part of GetOut! is that the AI isn't running on my backend.

I use Qwen3 locally in the user's browser through Hugging Face Transformers.

The architecture looks like this:

                 ┌─────────────────────┐
                 │      Player         │
                 │   React Frontend    │
                 └──────────┬──────────┘
                            │
                            ▼
                 ┌─────────────────────┐
                 │       Qwen3         │
                 │  Local Browser AI   │
                 └──────────┬──────────┘
                            │
                    Spatial Plan
                            │
                            ▼
                 ┌─────────────────────┐
                 │    FastAPI Backend  │
                 │      Render         │
                 └──────────┬──────────┘
                            │
                            ▼
                 ┌─────────────────────┐
                 │      Valhalla       │
                 │   OSM Road Routing  │
                 └─────────────────────┘

1. Qwen3 creates the challenge

When the challenge starts, Qwen3 is loaded directly in the browser.

It receives the challenge context and produces a semantic description such as:

{
  "shape": "triangle",
  "size": "large",
  "pace": "normal",
  "title": "Triangle Challenge"
}

The frontend then converts that semantic response into a structured spatial plan containing the shape, checkpoints, rotation, and target dimensions.

For example:

START
  ↓
CHECKPOINT A
  ↓
CHECKPOINT B
  ↓
START / FINISH

2. The backend handles multiplayer coordination

The FastAPI backend doesn't run the AI model.

Instead, it receives the spatial plan from the browser and handles:

session creation
join codes
player connections
WebSocket communication
player locations
challenge synchronization
route generation

Sessions are synchronized in real time using WebSockets.

3. Real roads replace impossible straight lines

A geometric triangle looks great mathematically, but you can't necessarily walk in a perfectly straight line through buildings, rivers, highways, or private property.

So instead of forcing the road network to literally draw a triangle, GetOut! treats the generated shape as a checkpoint challenge.

Valhalla then finds walkable/cyclable routes between those checkpoints.

This makes the challenge work in the real world.

4. Each player gets their own version of the challenge

This was one of my favorite parts to implement.

If two friends start several kilometers apart, they shouldn't have to travel to the same physical triangle.

Instead:

Both players get the same type of challenge, but it is generated relative to their own starting locations.

That makes the competition fair while still letting both people start from wherever they are.

Why Does Open Innovation Matter?

For me, the biggest advantage of open innovation was control.

A closed AI API could have generated the challenge description, but then the entire experience would depend on sending a user's location and prompt to an external service.

With a local open-weight model, I could experiment with running the AI directly on the user's device.

That creates some interesting possibilities:

Privacy: location-based challenge generation doesn't require sending the AI inference itself to a third-party AI API.
Lower backend cost: my server doesn't need to run an expensive model.
Offline potential: the AI component can potentially work without a separate inference server once the model is available locally.
Experimentation: I can change the prompt and challenge logic without being tied to a proprietary API.
Transparency: I can see exactly where the model's output ends and my application logic begins.

It also made the architecture more interesting.

Instead of:

User → Cloud AI → Backend → Map

I could build:

User
 ↓
Local AI
 ↓
Spatial Plan
 ↓
Backend
 ↓
Real-world route

The AI becomes part of the application itself rather than just an API call hidden behind the server.

My Agent Session

I didn't use an agent for this project, so I don't have an Agent Session to include here.

Instead, the AI component is Qwen3 running locally in the browser.

I wanted to keep the architecture intentionally simple: the model generates the semantic challenge, while deterministic application code handles the geometry, multiplayer state, and routing.

Prize Categories

🏆 Best Use of Render

GetOut!'s multiplayer backend is deployed on Render.

Render hosts the FastAPI server responsible for:

multiplayer session creation
join-code management
WebSocket connections
synchronizing the two players
receiving spatial plans
generating real-world routes

The frontend is deployed separately on Vercel, while Render acts as the real-time backend that connects the players together.

Tech Stack

Part	Technology
Frontend	React + Vite
Maps	React Leaflet
Local AI	Qwen3
AI Runtime	Hugging Face Transformers
Backend	FastAPI
Real-time communication	WebSockets
Routing	Valhalla
Map data	OpenStreetMap
Frontend hosting	Vercel
Backend hosting	Render

Final Thoughts

I started with the idea of making something that would simply encourage two people to get outside.

But while building it, I became much more interested in the boundary between AI-generated ideas and deterministic real-world systems.

Qwen doesn't need to know how to navigate a city.

Valhalla doesn't need to know what a "fun challenge" is.

The frontend doesn't need to understand how an LLM works.

Each part does one thing, and together they turn a generated idea into something you can actually walk.

And that's the whole point of GetOut!:

Don't just go for a walk. Give yourself somewhere to go. 🚶‍♀️🗺️

You can check out a sample I did with my friend here!

My friend was able to complete the challenge before me! lol

Thank you for reading my submission!

Decrypting with Ghosts

NIKITHA S — Sun, 21 Jun 2026 16:18:29 +0000

This is a submission for the June Solstice Game Jam

What I Built

I built an atmospheric, web-based cryptographic puzzle game using Twine (Harlowe 3). Together with the ghost of Alan Turing! you must crack five distinct historical and digital ciphers to unlock a mysterious mechanical core.

My goal was to blend historical text-based cryptography with rewarding visual mechanics. Every time the player solves an encrypted message, a digital flower dynamically sprouts and blossoms in unison with their achievements, populating a persistent garden.

You can give the game a go here : {https://stargalax.github.io/June-Solstice-Game-Jam/}

Relation to the Theme

The game embraces the June Solstice theme through a deliberate aesthetic contrast and its core gameplay loop. While the background is locked in terminal darkness, your progress acts as a digital solstice. The entire experience mirrors a time-lapse organic transformation: by overriding security locks, the player coaxes digital life out of a cold machine, culminating in a fully bloomed, glowing neon summer garden at the absolute peak of the solstice loop.

Video Demo

Below is a brief look at the custom-engineered visual reward loop in action.

As seen in the video, the game tracks player victories with precision. When a cryptographic multiple-choice question is answered correctly, a flower blooms.

Code

You can explore the full interactive framework, the custom Twine macro logic, and our custom CSS animation stylesheet here:

stargalax / June-Solstice-Game-Jam

How I Built It

Building an interactive fiction experience with persistent, fluid animations presented unique challenges in Twine's default browser rendering engine:

The Cryptographic Loop: Rather than standard general knowledge trivia, I converted the interactive loop into quick-thinking cryptographic hurdles, featuring Caesar Shifts (-3), Reverse Ciphers, ancient Atbash Ciphers, 8-bit Binary ASCII streams, and a matrix-style Grid Cipher.
Defeating the Animation Glitch: In early iterations, changing rooms forced the browser to re-render all CSS items from 0px to 100px, causing a frantic, messy "double-growth" loop on screen. To solve this, I decoupled static flowers from active ones using an intentional .bloom-now class state.
Dreamy Ambience Integration: To combat aggressive modern browser auto-play blocks on music elements, I routed a soft, floating ambient pad track through global JavaScript triggered dynamically by the player's very first interaction click.

Prize Category

🎖️ Best Ode to Alan Turing

This project was built from the ground up to celebrate the legacy and intellectual brilliance of Alan Turing. Instead of a passive biography, players step directly into his footsteps.

By interpreting raw binary bitstreams , navigating morphological patterns, and working side-by-side with his digital phantom, the game acts as a living, breathing monument to his foundational contributions to computer science and cryptography. The bittersweet finale on the solstice peak serves as a heartfelt thank you to his enduring legacy.

DEV Community: NIKITHA S

Receipts,Not Rumors

What I Built

Demo

Code

stargalax / receipts-not-rumors-web

Receipts, Not Rumors

Features

How I Built It

Why Does Open Innovation Matter?

Partner Category used

QueueInk

What I Built

Demo

Code

stargalax / QueueInk

title: queueInk emoji: /'o-o' sdk: gradio sdk_version: 5.50.0 app_file: app.py pinned: false

How I Built It

Why Does Open Innovation Matter?

Prize Categories

Check out my submission for the #Hacktoberfest conducted by MLH x Dev community! Would love to hear your thoughts on this.Thank you

GetOut!

GetOut!

🚶 GetOut! — Draw Your Route, Not Just Your Steps

What I Built

Demo

How to try it

Code

How I Built It

1. Qwen3 creates the challenge

2. The backend handles multiplayer coordination

3. Real roads replace impossible straight lines

4. Each player gets their own version of the challenge

Why Does Open Innovation Matter?

My Agent Session

Prize Categories

🏆 Best Use of Render

Tech Stack

Final Thoughts

Decrypting with Ghosts

What I Built

Relation to the Theme

Video Demo

Code

stargalax / June-Solstice-Game-Jam

stargalax / June-Solstice-Game-Jam

How I Built It

Prize Category

🎖️ Best Ode to Alan Turing

title: queueInk emoji: /'o-o'
sdk: gradio sdk_version: 5.50.0 app_file: app.py pinned: false