DEV Community: Parnita Singh

Lunar Hollow: The Vanished Webmaster

Parnita Singh — Sat, 31 Oct 2026 19:08:32 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine

What I Built

Lunar Hollow is a small offline mystery. Nightowl_Ren, the webmaster of a 2000s fan site, stopped posting on March 14, 2004. Four guestbook fans each left a clue, and the archive password comes from putting those clues together.

I read the theme as a ghost story told through an old website. The case board is the haunted part: pinned notes, red string, and a photo of the missing webmaster. The clues are written to reward players who check the source code, since the password pattern is hidden in an HTML comment.

Demo -
https://drive.google.com/file/d/1Th7n308Oixq_3CXmGPOLSX-d1MUWWOC3/view?usp=sharing

Code -
https://github.com/parnita-Singh/LUNAR-Week4/tree/main

The repo has three files: index.html (the page and case board), app.js (the clues and password check), and README.md. Open index.html in a browser to play. No install is needed.

How I Built It

The game is plain HTML, CSS, and JavaScript, with no framework and no build step. The clues and the password are fixed in app.js.

The open-source AI is not yet in the game. The current version runs without any model. The planned next step is a local open-weight model, run through Ollama, that rewrites each suspect’s answers in their own voice. The answers would stay fixed in code, so the model couldn’t invent clues or reveal the solution. I haven’t built or tested that step, and I don’t want to claim it works yet.

Why Does Open Innovation Matter?

Open tools make this kind of project possible without a service:

It runs offline, with no server and no API key.
Anyone can read the source, fork the case, or write a new mystery in app.js.
It costs nothing to run, and nothing is billed per play.

Once a local open-weight model is added, the same argument extends to the AI: the model runs on the player’s machine, so the dialogue never leaves it, and the model can be swapped without rewriting the game.

The Spirit of It

The ghost in this story is the missing webmaster. The old-web look, with its dead links and unanswered guestbook, is meant to feel like a site someone left behind. If it lands for players, it’s because the page feels abandoned, and the clues are how you bring Ren back.

I made this over the weekend, it will only take a min. check it out

Parnita Singh — Mon, 26 Oct 2026 17:31:06 +0000

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

Parnita Singh

Oct 25

PDFme, the offline PDF toolkit I built after my college fest nearly broke me

#devchallenge #hf26challenge #programming #ai

4 min read

[Boost]

Parnita Singh — Sun, 25 Oct 2026 18:40:31 +0000

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

Parnita Singh

Oct 25

PDFme, the offline PDF toolkit I built after my college fest nearly broke me

#devchallenge #hf26challenge #programming #ai

4 min read

[Boost]

Parnita Singh — Sun, 25 Oct 2026 18:32:57 +0000

Parnita Singh

Oct 25

Ever Struggled with PDFs, which out PDFme

Parnita Singh

Oct 25

PDFme, the offline PDF toolkit I built after my college fest nearly broke me

#devchallenge #hf26challenge #programming #ai

3 min read

1 min read

Ever Struggled with PDFs, which out PDFme

Parnita Singh — Sun, 25 Oct 2026 18:32:44 +0000

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

Parnita Singh

Oct 25

PDFme, the offline PDF toolkit I built after my college fest nearly broke me

#devchallenge #hf26challenge #programming #ai

4 min read

PDFme, the offline PDF toolkit I built after my college fest nearly broke me

Parnita Singh — Sun, 25 Oct 2026 18:28:53 +0000

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

What I Built

PDFme is a local, offline PDF toolkit for large print designs. It can:

compress a huge PDF down to a size you can actually share
remove image backgrounds with an open-source AI model (ISNet, through rembg, with other models to pick from)
label pages with Gemma, a local open-weight model run through Ollama
merge and split PDFs by size or by page range Everything runs on your own computer. Your files are never uploaded, and there is no account, no cloud service and no internet needed after the one-time downloads (details in the serious part at the bottom).

Now, it sounds cool. When I needed it, it was nowhere near cool.

Backstory

I was half dead, one step away from zombie. That is what a university cultural fest does to you: endless banners, posters and artifacts, each one due to a vendor at a specific time, in a specific size, in a specific file type, with background or without background.

Send a Drive link? Not enough. Email? 25 MB limit. WhatsApp? 2 GB limit, so my merged PDF could not go in one piece. I had to sort through everything, pick the right files, and send each one carefully, one by one.

All of that went blaaaaaaaast in my head at once. I did not give up, because I knew what I had to fix. The fest ended on the 23rd, I started PDFme on the 24th, and as I write this on the 25th, I feel better. Now whenever I see someone struggling with a PDF, I get my cool moment: "check out PDFme." It works, and I will tell you exactly where it doesn't, in the serious part below.

Demo

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

File	Before	After	What it did
Fest standee, BIBB 3x6	515.9 MB	39.0 MB	Print copy
Fest standee, BIBB 3x6	515.9 MB	284.9 MB	Fit to size at 300 dpi

Code

https://github.com/parnita-Singh/PDFme-week3

How I Built It

I used Cursor. I started with Grok 4.6 (medium), and when it hit its monthly limit, I took a pause, screamed and switched to Claude Haiku 5.5.

The open pieces:

Gemma through Ollama, for page labels
Background removal with rembg, using the ISNet model by default
PDF libraries: pikepdf and pypdf for reading and writing PDFs, Pillow for images, pypdfium2 for rendering pages, and Gradio for the web page

Along the way I learned things I did not know before: how an image has layers, what an SMask is, and how DPI affects image quality.

Why Does Open Innovation Matter?

You can always argue, "just give it to GPT." My counter question: would you trust your Aadhaar card, passbook and cheque book details to a cloud chatbot?

That is where PDFme enters, ladies and gentlemen. yeahhhhaaa!

Because the models run on your own machine:

your private files never leave your computer
it works without internet once the models are downloaded
it costs nothing to run
you can pick a different background model from a list, and set a different Gemma model name

I know I'm writing like a crazy person, but this post is 100% human written.

This was also the first time I built something outside the rat race of having a project on my resume or GitHub. I built it for a problem I actually hit, and I would bet other people hit it too. It is 2026, we have AI that writes code, and people still lose hours to PDFs. I solved it, and I love it.

It is cool. I will give you a minute. Admit it 😎

Now the serious part

What I tested: 15 real fest PDFs, each 510 to 700 MB. I verified background removal, splitting, merging and compressing on all of them.

Limits:

Tested on files of 510 to 700 MB.
"Fit to size" uses a 2000 MB default, the same as WhatsApp's 2 GB document limit. It steps the resolution down from 300 dpi to 100 dpi, and writes no file if nothing reaches the limit.
Background removal changes only the images you choose. A photo covering 90% or more of the page is skipped by default. You can raise that limit, or tick the image you want to process.
Images that already have transparency, and vector art, are left alone.
Gemma page labels need Ollama and a one-time model download. I haven't checked them on the banner yet.
I switched off Wi-Fi and ran the print copy and page-range split with no internet connection. The background model needs a one-time download first, so it must be on the computer before you go offline.

Do not forget to star the repo ⭐, because you are gonna love PDFme.
heeehheee

Clover - The LEAF Hunt

Parnita Singh — Sun, 11 Oct 2026 18:17:26 +0000

What I Built✨

Leaf Hunt is an offline, audio-first plant scavenger hunt. Each week it generates five seasonal clues based on your local last spring frost date, like “find a leaf with five leaflets” or “find something still flowering.” You walk, point your phone at a plant, a local open-weight vision model identifies it, and you describe what you found by voice. Finds go into a local journal that you can export as a styled HTML page. The screen is only needed at the start and end.

It’s for anyone who wants a reason to go outside: families, hikers, students, and people who enjoy birding or nature walks without needing a signal.

Demo
Drive link🍀 -

GitHub link🍀 - https://github.com/parnita-Singh/leaf-hunt

How I Built It
Vision: a small quantized open-weight vision-language model, served by Ollama or llama.cpp
Speech-to-text: whisper.cpp
Text-to-speech: Piper
Storage: SQLite
Interface: Typer CLI, running on a laptop or Raspberry Pi

Clue selection is rule-based, using a bundled seasonal plant dataset and the frost date. The LLM only phrases the clues. Every model sits behind one adapter interface, so you can swap backends in config.toml without touching app code.

Why Does Open Innovation Matter?
It works offline. Trails often have no signal, and nothing calls a remote API.
Your data stays with you. Photos of places and voice notes never leave the device.
It costs nothing to run. There are no per-request fees, so you can play all season.
The models are swappable. I can try different vision models without rewriting the app.

My Agent Session

I built Leaf Hunt in Cursor’s Agent mode, one step at a time, reviewing each stage before moving on. The session is saved with DevRelay and embedded below.

The Database Model That Changed My Mental Model

Parnita Singh — Mon, 14 Sep 2026 15:32:06 +0000

Coming from Web2, I initially pictured a blockchain as something closer to a database with tables, rows, and a backend controlling everything.

Solana made my simple one thought perspective to somehing totally different a new feild, upcoming future, igniting new ideas.

On Solana, everything is an account. Wallets, programs, and data storage all use the same account model. Every account has five fields:

lamports - its SOL balance mainly used in backend by the computer, where 1 SOL = 1 billion lamports
data - a byte array containing its state
owner - the program that controls the account
executable - whether the account contains a program
rent_epoch - a deprecated field

The owner field is especially important for security. Only the owning program can modify an account's data or debit its lamports. Other users can still credit lamports to a writable account.

The concept that surprised me most was that programs don't store their own state.

Coming from Web2, I tend to think of application code and its database as one connected system. On Solana, programs are stateless code accounts, while their state lives in separate data accounts.

A useful analogy for me is:

Program = web server and Data accounts = database

Another concept I learned is rent exemption: accounts need a minimum lamport balance based on their data size to remain on-chain.

The more I learn, the more Solana's account model starts to feel less mysterious and more like a completely different way of designing applications.

From HTTP Requests to Atomic On-Chain Transactions

Parnita Singh — Mon, 17 Aug 2026 17:12:15 +0000

Coming from Web2, I initially thought of a Solana transaction like an API request:

send request -> server processes it -> get response

But after working with Solana transactions, I realized the mental model is quite different.

A Solana transaction is a package containing things like signatures, instructions, accounts, and a recent blockhash. The transaction is signed before it can be accepted, and the instructions describe exactly what the network should execute.

One thing that really clicked for me was the idea of atomicity.

With an ordinary API, I might send a request to my backend and then update a database. There can be multiple steps involved.

With a Solana transaction, multiple instructions can be included together, and they are executed atomically. The transaction either succeeds as a whole or fails.

I also learned that transactions aren't valid forever. They use a recent blockhash, which gives them a limited validity window. That was very different from the API requests I'm used to working with.

During my experiments, I also ran into a 429 Too Many Requests error while polling transaction status. That was a useful reminder that even when the blockchain is decentralized, my application still depends on RPC infrastructure to communicate with it.

The biggest takeaway from Day 20:

A Solana transaction isn't simply a request to a server. It's a signed set of instructions that asks the network to make an atomic state change.

That shift in thinking is making Solana development start to feel much clearer.

2 weeks in Solana, here what I learned !

Parnita Singh — Tue, 11 Aug 2026 13:22:10 +0000

Two Weeks of Solana, here a look into my week !

I’m now 14 days into #100DaysOfSolana, and looking back at the first two weeks, I realize how much my understanding of Solana has changed.

When I started, I mostly thought of a wallet as a place where you keep cryptocurrency. Now I understand that a wallet is built around a cryptographic keypair—the public key represents your on-chain identity, while the private key proves ownership and the part of what to share and what I can do with my keys and info.

One of the biggest surprises for me was how much blockchain data is publicly accessible. Working with Solana's RPC calls made the idea of a “public database” feel real. you know at first I was like what the hell if everyone can know about me from my keypair something is wrongh here, but soom realised But then I realized that my public key isn't my secret. It's more like my public identity on the blockchain. The thing that actually proves ownership is my private key, and that's the part that must never be shared.

That was probably one of the biggest mindset shifts for me during these first two weeks.
soon I could query balances, accounts, and transaction history directly instead of going through a private backend like I normally would in Web2.

The comparison between traditional databases and Solana accounts also helped things click. Tables and rows became accounts, SQL queries became RPC calls, and writes happen through signed transactions.

But I'm definitely not at the point where everything makes sense yet. 😅 I’m still trying to understand the deeper relationship between accounts, programs, transactions, and instructions.

And honestly, that's what makes me excited for the next few weeks.
I started this challenge trying to understand Solana.
well I know I ahve slipped through few days first it was my healtha nd mood swings then I took some days off to blow off the steam and the part of how much I need that :) so no regrets there 😙
Now I'm gonna complete this journey & understand how to think in Solana, web 3, blockchain.

87 days to go! 🚀

100DaysOfSolana #Solana #Web3 #Blockchain #DEVCommunity #BuildInPublic #MLH

My First Week with Solana Wallets

Parnita Singh — Fri, 24 Jul 2026 18:47:52 +0000

Well I guess it is a week now,I really don't know how quickly it passed and it is my 7th day of #100DaysOfSolana. I had really no idea when I started at that time to me, I thought like, "I guess it seems intersting and it would come in use after completing SHE fi S'16 "and now one moment that stood out was connecting my Phantom wallet to a web application I built and The biggest mindset shift for me was realizing that a wallet isn't just a place to store SOL-it's my on-chain identity. Coming from Web2, where identity revolves around emails and passwords, learning that a cryptographic keypair can represent ownership across an entire blockchain ecosystem was fascinating.

Along the way, I generated wallets programmatically, built a persistent wallet, explored SOL and lamports, connected browser wallets to a dApp, compared different wallet types, and learned how public and private keys work together to secure digital ownership.

here are some stuff i clicked througout this week

et interact with the Solana Devnet.

I'm excited to keep building and dive deeper into transactions, programs, and smart contracts in the coming weeks.

@solana_devs
93 days to go! 🚀

From Usernames to Keypairs: A Primer on Identity on Solana

Parnita Singh — Thu, 23 Jul 2026 16:20:12 +0000

As a Web2 developer, I always thought of identity as an email, username and password. Each app had its own login system and companies controlled my account access.

Learning Solana totally changed that perspective.

On Solana, your identity begins with a cryptographic keypair. Your public key is your wallet address, which is visible to everyone, and your private key is used to prove ownership when signing transactions. No usernames, no passwords, no central database controlling your account.

The best analogy I could draw was SSH keys. You prove your identity to a server with a private key, and Solana does the same for your wallet to the blockchain.

The difference is that you authenticate with the entire network instead of a single server.

Another realisation was that a wallet is more than just a place to hold SOL. The same identity works across decentralised apps, so you can own tokens, interact with smart contracts, and participate in governance without creating a new account for every platform.

There is no “Forgot Password” option here, unlike Web2. If you lose your private key or recovery phrase, there is no company that can restore access for you. That is all your responsibility and control

This shift from company-controlled identity to cryptographic ownership has been one of the most interesting concepts I’ve learned so far in my #100DaysOfSolana journey. It totally changes my perspective on digital identity and ownership.