DEV Community: Nimesh Thakur

I Had a Story. I Turned It Into a Song. Now I'm Building a Community.

Nimesh Thakur — Tue, 10 Mar 2026 12:03:36 +0000

I read a lot.

Books, blogs, development docs, ancient texts — Vedas, philosophy, things most people skip.

After all that reading, one thing became clear:

We are always free. We are the sky. Clouds pass through. They don't stay.

That thought became a blog.

Then one day I asked myself — why does it have to stay as words?

The Idea

I'm not a singer.

No music training. No studio. No experience.

But I had something real to say.

And today, that's enough.

How I Made My First Song

Step 1 — Blog became lyrics

I gave my blog to AI. ChatGPT, Gemini, Claude.

Asked them to turn it into song lyrics.

Then I read every version slowly. One test: does this still feel like mine?

If yes — move forward.

Step 2 — Lyrics became a style

I went back to AI. Described the emotion I wanted.

It helped me find the right words: beats, mood, instruments, energy.

Step 3 — Style became a song

I put the lyrics and style into Suno AI.

It generated a full song. Vocals. Instruments. Everything.

In seconds.

I generated many songs. Listened to all of them. Most were good.

Then one came on — and I got goosebumps.

That was the one.

A Note on ADO

My favourite singer is ADO — a Japanese artist.

If you haven't heard her, go listen right now.

She doesn't just sing. She bleeds into every note.

That's what I was chasing. Not technically. Emotionally.

The Album

I made 4 songs. Put them on YouTube.

Not for views. Not for growth. Not for anyone else.

Just to know — I made this. This came from inside me.

My two favourites:

🎵 First Song
🎵 Fourth Song

Then a Bigger Question Came

Everyone is chasing goals.

Timelines. Career ladders. The next milestone.

Earth is starting to feel like a very serious race track.

What if we made it more interesting?

SONGUILD

One month. One song. One community.

That's it.

You have 30 days. Make something. Anything.

A song born from your experience — a project you built, a bug that broke you, a book that changed you, a feeling you couldn't explain.

At the end of the month, we all gather and review together.

Not silently. Not with a form. Together.

What gets rated:

🎵 Overall Song — does it land?
✍️ Lyrics — is there a real thought behind it?
🎧 BGM — does the sound match the feeling?
🎬 Visuals — the YouTube presentation

End of month awards:

Best Song
Best Lyrics
Best BGM
Best Visuals

Why This Is Different

Most challenges are consistency games.

Post every day. Don't break the streak. Show up even when empty.

SONGUILD is a creativity game.

One month. No daily pressure. No burnout.

Just: here is a blank canvas — make something real.

You Don't Need to Be a Singer

I wasn't.

You just need something worth saying.

A late night debugging session that taught you patience.
A framework you loved then outgrew.
A moment of clarity at 2am.
Something you read that quietly changed everything.

That's your song.

Come Join

Right now SONGUILD is small.

Maybe it's just me when you read this.

Maybe it's something much bigger.

Either way — the door is open.

We're starting with songs. But when the community grows, we grow with it. New formats. New ideas. New ways to create together.

The song is just the beginning.

🎮 Join SONGUILD (Discord link in comments)
🎵 The album that started it all — links above
📖 The blog that became the first song — The 90% I Missed

I'm 21. I read everything I can. I write what I learn. And now — I make songs.

We are always free. Come create something.

The 90% I Missed While Chasing the 10%

Nimesh Thakur — Sun, 15 Feb 2026 04:16:06 +0000

I'm 21. I don't have answers. I don't have a success story to sell you. What I have is a growing pile of questions and a strange sense that I spent years preparing for life instead of actually living it.

This isn't about productivity hacks or finding your passion. This is about noticing what was always there while I was looking somewhere else.

Borrowed Beliefs

As a child, I lived on autopilot with beliefs I never chose. "Study hard today and your future will be good." My parents said it. Teachers repeated it. Society nodded in agreement. So I believed it too, because everyone around me did. When your entire environment validates something, you don't question it. You just accept it as truth.

I wasn't stupid for believing it. I was a kid. Kids absorb their surroundings like water soaking into cloth.

Somewhere in 11th and 12th grade, something shifted. I didn't consciously decide to step out of the race, but I did. I stopped caring about rankings and comparisons. I became more curious, more confused, and honestly, more chaotic. I had flaws. Ego. Moments of what I'd call an immature or even 'evil' personality. But I was improving, slowly, without realizing it.

The Reading That Broke Things Open

Around 17, I started reading. Not because I loved it—I actually hated it at first. Books felt slow and boring compared to movies and YouTube. I started with comics, light stuff like Chacha Chaudhary, just to ease into it.

But reading did something unexpected. It made me curious about things I'd never questioned before. Who am I? What is society? Why do humans follow this endless cycle: study, job, marriage, children, repeat, death? Why does everyone talk about God but no one asks who created God? Why do animals seem freer than humans, even though we call ourselves intelligent?

I read things that most people don't stumble into at that age. Tantra Sutra. Books on awareness and consciousness. I wasn't seeking enlightenment. I was just trying to understand why life felt so unnecessarily complicated in my head.

I also watched things that hit differently. One Piece. Pixar's Soul. These weren't just entertainment—they became mirrors. Luffy doesn't obsess over becoming Pirate King in some distant future. He lives fully while moving toward it. Soul showed me how people can spend their entire lives preparing to live, only to realize they forgot to actually live.

These didn't make me spiritual or wise. They made me question everything I thought was normal.

The Trap of Goals

At 19 and 20, I became obsessed with finding my purpose. I tried everything. Car designing. Army. Navy. Airforce. Cybersecurity. Development. Bug hunting. I kept waiting for something to "click," for some voice inside to say, "Yes, this is it."

Nothing clicked.

I wanted to earn millions. Not for cars or luxury. I wanted to fix things—villages, water systems, the environment. I believed that once I had enough money, I could finally do something meaningful.

I realize now how flawed that was. Action matters more than imagined future money. Waiting for the perfect condition is just another way of not starting.

Goals became my mental prison. I started living entirely in two places: the past, with regret over what I didn't do, and the future, anxious about what I hadn't achieved yet. The present? I was barely there.

I thought goals were 90% of life. Work toward something. Achieve it. Move to the next. Repeat until death. That was the formula everyone seemed to follow.

The 90% I Wasn't Seeing

Then I realized something that felt obvious once I saw it, but I had missed it for years.

Goals are maybe 10% of life. Maybe.

The other 90%? It's everything else.

It's talking to people and actually listening instead of waiting for your turn to speak. It's eating food and noticing the taste instead of scrolling while you chew. It's walking and feeling the ground under your feet. It's breathing and knowing you're breathing. It's hearing birds in the morning. It's sitting with your family without thinking about tomorrow. It's being present with strangers.

This 90% doesn't show up on your resume. It doesn't trend on social media. It doesn't make you rich or famous. But it's where life actually happens.

And I had been missing it. Completely.

I was so focused on becoming someone in the future that I forgot I already am someone right now. I was treating the present as a waiting room for a better tomorrow that never quite arrived.

Witnessing vs. Existing

There's a difference between existing and witnessing.

Existing is going through the motions. Eating while thinking about work. Walking while replaying a conversation. Breathing without noticing. Reacting to everything out of habit.

Witnessing is different. When you eat, you actually taste. When you walk, you feel your feet on the earth. When you breathe, you notice the air moving in and out. You act, but you're aware. You respond instead of reacting.

This isn't some mystical state. It's just being here instead of being lost in your head.

One Piece taught me this in a way books couldn't. Luffy doesn't postpone joy until he finds the One Piece. He's fully alive in every moment while moving toward his goal. He's present with his crew. He laughs, fights, eats, and lives completely. The journey isn't a burden to endure until he reaches the destination. The journey is the life.

Soul showed me the opposite—what happens when you're so obsessed with finding your purpose that you forget to live while searching for it. Joe spent his whole life waiting for the one moment that would make everything make sense, only to realize life was happening the whole time, and he wasn't there for it.

What I'm Not Saying

I'm not saying abandon goals. I'm not saying responsibility doesn't matter. I'm not saying sit under a tree and meditate all day.

I'm saying something simpler.

Move toward your goals, but don't become psychologically enslaved by them. Work, but don't let work consume the 90% that makes life worth living. Plan for the future, but don't sacrifice the present to an imagined tomorrow.

Life isn't a problem to solve. It's not a race to win. It's not a puzzle where you finally figure everything out and then relax.

Life is this. Right now. The breath you just took. The light coming through your window. The sound of the world around you.

Still Learning

I'm still figuring this out. I still get lost in my head. I still worry about the future. I still set goals and chase them. But now I'm trying to notice when I'm here and when I'm not.

I'm learning to witness instead of just exist. To listen instead of just hear. To see instead of just look.

I don't know if this is wisdom or just confusion that sounds better organized. I'm 21. I have more questions than answers. I have more failures than successes. I have more doubts than certainty.

But I'm starting to think that's okay.

Maybe life isn't about having it all figured out. Maybe it's about being present while you figure it out. Maybe the goal isn't to reach some final destination where everything makes sense. Maybe it's to live fully while moving forward, even when nothing makes sense.

I'm still reading. Still questioning. Still learning. Still missing the present sometimes while thinking about tomorrow.

But I'm trying.

And maybe that's enough for now.

404ping: From "It Works" to "It's Actually Really Good" 🚀

Nimesh Thakur — Sun, 08 Feb 2026 03:45:24 +0000

How I spent 3 months turning a simple CLI into something I'm genuinely proud of

Where We Left Off

Back in November, I wrote about 404ping v2 — my lightweight API testing CLI that was basically "curl with memory."

It could:

Send HTTP requests (obviously)
Store variables globally or per-collection
Save requests to collections
Run saved requests with overrides
Show different output modes (headers, connection info, TLS details)

People actually used it. Bug hunters messaged me. Developers starred it on GitHub. I was happy.

But then I kept using it. And every time I reached for 404ping in my actual workflow, I'd hit a wall and think: "Why can't it just...?"

So I spent the next three months answering that question.

The "Why Can't It Just..." Moments

Moment 1: "Why can't it just SAVE the damn request while I'm testing it?"

The old way:

# Test the request first
404ping request {{host}}/api/login -X POST -d '{"email":"test@test.com"}'

# Looks good? Now save it (copy-paste hell)
404ping collection save myapp login -X POST {{host}}/api/login -d '{"email":"test@test.com"}'

I was literally typing the same request twice. That's stupid.

What I built: Quick Save

# Test AND save in one command
404ping request {{host}}/api/login -X POST \
  -d '{"email":"test@test.com"}' \
  --save myapp.login

One flag. Done. The request you just tested is now saved. No copy-paste. No context switching.

This single feature changed how I use 404ping. Now I just add --save to everything and build my collection as I explore APIs.

Moment 2: "Why can't it just validate the response automatically?"

I was constantly doing this:

404ping run myapp:login
# Check status code manually
# Check if token exists manually
# Grep for specific values manually

What I built: Inline Assertions

404ping request https://api.example.com/users/42 \
  --assert "status=200" \
  --assert "json.userId=42" \
  --assert "json.role=admin"

Now 404ping tells me if something's wrong. Perfect for smoke tests or CI/CD:

404ping run myapp:login --assert "status=200" --assert "json.token!=null"
# Exit code 0 if passes, 1 if fails

Moment 3: "Why can't it just use the token from the previous request?"

This was the big one. The workflow that made me want to rebuild everything:

Before (the painful way):

# 1. Login
404ping run myapp:login
# Response: {"token": "eyJhbGc..."}

# 2. Manually copy token
404ping set token:eyJhbGc...

# 3. Use token in next request
404ping run myapp:get-profile

Every. Single. Time. Manual token copying. This is 2025, why am I doing this?

What I built: Request Chaining & Variable Extraction

404ping sequence auth:login users:me \
  --extract token=json.token \
  --bearer {{runtime.token}} \
  --assert "status=200"

What happens:

Runs auth:login
Extracts json.token from response → stores as {{runtime.token}}
Runs users:me with Authorization: Bearer {{runtime.token}} header
Asserts both succeeded

No manual copying. No intermediate steps. Just declare the flow and it works.

Real-world example:

404ping sequence \
  auth:login \
  users:create \
  posts:create \
  posts:list \
  --extract token=json.auth.token \
  --extract userId=json.user.id \
  --bearer {{runtime.token}} \
  --assert "status=200"

This is what made 404ping actually useful for real workflows.

Moment 4: "Why can't it just parse the JSON for me?"

I was piping everything to jq:

404ping run myapp:users | jq '.data.users[].email'

What I built: Built-in JSON Filtering

404ping request https://api.example.com/posts/1 \
  --filter "json.comments[*].{author: author.name, text: body}"

And you can extract values directly into variables:

404ping request https://api.example.com/auth \
  --extract token=json.access_token \
  --extract userId=json.user.id \
  --extract trace=header.X-Trace-Id

Extracted values go into {{runtime.*}} and can be used in chained requests.

Moment 5: "Why can't it just switch environments easily?"

Testing across staging/production was painful:

Before:

404ping set host:https://staging-api.myapp.com
# Test stuff
404ping set host:https://api.myapp.com
# Test stuff

What I built: Environment Profiles

Create .env.staging:

BASE_URL=https://staging-api.myapp.com
API_KEY=staging_key_123
TIMEOUT=10000

Create .env.production:

BASE_URL=https://api.myapp.com
API_KEY=prod_key_456
TIMEOUT=5000

Now switch with one flag:

404ping --env staging run myapp:users
404ping --env production run myapp:users

You can even layer multiple env files:

404ping --env staging --env-file secrets/.overrides.env run billing:charge

Moment 6: "Why can't it just work with Postman collections?"

My team uses Postman. I wanted to use 404ping. We were stuck in different worlds.

What I built: Postman Import/Export

# Import their collection
404ping postman import team-api.postman.json -c teamapi

# Work in terminal with 404ping's speed
404ping run teamapi:login
404ping run teamapi:create-user --assert "status=201"

# Export back to share updates
404ping postman export teamapi -o team-api.postman.json

Now I can:

Import team's Postman collections
Work faster in terminal
Export when I need to share
Best of both worlds

Moment 7: "Why can't it just run scripts before/after requests?"

Sometimes you need custom logic — dynamic signatures, complex validation, custom logging.

What I built: Hooks & Scripts

404ping request https://api.example.com/orders \
  --pre-script @scripts/add-signature.js \
  --post-script "console.log('Order created:', response.data.orderId)"

Pre-scripts can modify the request before it's sent.
Post-scripts can validate, log, or extract data from responses.

Moment 8: "Why can't it just benchmark this endpoint?"

Before: Install ab or wrk, figure out syntax, parse output...

Now:

404ping request https://api.example.com/heavy \
  --benchmark 10

Runs it 10 times and shows:

Min/Median/P95 latency
Success rate
Average response size

Perfect for quick performance checks.

What 404ping Actually Is Now

Let me show you a real workflow — the kind I run every day as a bug bounty hunter:

Scenario: Testing a new API target

# 1. Setup environment
404ping set host:https://api.target.com

# 2. Test and save login endpoint
404ping request {{host}}/auth/login -X POST \
  -d '{"email":"test@test.com","password":"password"}' \
  --save target.login \
  --assert "status=200"

# 3. Run a full authenticated flow
404ping sequence target:login \
  https://{{host}}/users/me \
  https://{{host}}/admin/dashboard \
  --extract token=json.access_token \
  --bearer {{runtime.token}} \
  --assert "status=200"

# 4. Found IDOR? Test multiple user IDs quickly
404ping run target:get-user -u "{{host}}/users/123" --assert "status=403"
404ping run target:get-user -u "{{host}}/users/456" --assert "status=403"
404ping run target:get-user -u "{{host}}/users/789" --assert "status=200"

# 5. Check TLS configuration
404ping request {{host}}/secure --tls

# 6. Benchmark for timing attacks
404ping request {{host}}/auth/check -d '{"user":"admin"}' --benchmark 100

That's a complete security test workflow in 6 commands. No Postman. No bash scripts. Just 404ping.

The Complete Feature List (What You Can Do Now)

Core Functionality:

✅ HTTP requests (all methods, headers, bodies)
✅ Global and collection-scoped variables
✅ Collections for organizing requests
✅ Quick save with --save flag
✅ Run saved requests with overrides

New Superpowers:

🧪 Assertions — Validate responses inline (--assert)
🔗 Request Chaining — Run sequences with variable extraction (sequence)
📊 JSON Filtering — Parse responses without jq (--filter)
💾 Variable Extraction — Capture values from responses (--extract)
🌍 Environment Profiles — Switch environments with --env
🔄 Postman Import/Export — Work with team collections
🪝 Hooks & Scripts — Pre/post request JavaScript (--pre-script, --post-script)
⚡ Benchmarking — Performance testing built-in (--benchmark)
🔐 Advanced Output Modes — --info, --connection, --tls, --debug

Security & Developer Experience:

🛡️ SSL verification by default (explicit --insecure to bypass)
📝 Comprehensive error messages that actually help
🔍 TLS/SSL certificate inspection
🌐 Connection debugging
✅ Input validation and path traversal protection

How to Use It (Quick Start)

Installation

git clone https://github.com/toklas495/404ping.git
cd 404ping
npm install
npm run build

Basic Usage

# Simple request
404ping request https://api.example.com/users

# POST with data
404ping request https://api.example.com/login -X POST \
  -d '{"email":"test@test.com","password":"secret"}'

# Save while testing
404ping request {{host}}/api/login -X POST \
  -d '{"email":"{{email}}"}' \
  --save myapp.login

# Run saved request
404ping run myapp:login

# Chain requests with token extraction
404ping sequence myapp:login myapp:profile \
  --extract token=json.token \
  --bearer {{runtime.token}}

# Switch environments
404ping --env staging run myapp:users

# Import Postman collection
404ping postman import api.postman.json -c myproject

Real Workflow

# 1. Setup
404ping set host:https://api.myapp.com

# 2. Test & save requests as you explore
404ping request {{host}}/auth/login -X POST \
  -d '{"email":"dev@myapp.com","password":"test123"}' \
  --save myapp.login \
  --assert "status=200"

# 3. Run authenticated flows
404ping sequence myapp:login myapp:get-profile myapp:list-posts \
  --extract token=json.access_token \
  --bearer {{runtime.token}} \
  --assert "status=200"

# 4. Debug issues
404ping run myapp:slow-endpoint --info --benchmark 5

# 5. Check security
404ping request {{host}}/secure --tls

The Numbers

Since v2:

Metric	Change
Features	+8 major features
Commands	`request`, `run`, `set`, `vars` → Added `sequence`, `postman`
Flags	+12 new flags (`--assert`, `--extract`, `--filter`, `--benchmark`, `--env`, etc.)
GitHub Stars	6 → Growing
Use Cases	Testing → Testing + CI/CD + Security Audits + Performance Testing

What I Learned

1. Listen to your own frustration

Every feature came from me getting annoyed using my own tool. The best product feedback is your own pain.

2. "Just one more flag" compounds quickly

--save seemed small. But it changed everything. Then --extract. Then --assert. Small conveniences add up to workflows you couldn't imagine before.

3. Interoperability > Lock-in

Adding Postman import/export wasn't admitting defeat. It made 404ping more valuable. Now teams can use both.

4. Security should be the default

SSL verification on by default. Explicit --insecure flag. If you want to be insecure, you have to type it out.

5. Documentation is code

Every new feature came with examples in the README. If users can't figure it out in 30 seconds, it might as well not exist.

What's Next

I'm not done. Here's what I'm thinking about:

Maybe Soon:

🔌 Plugin system — Let people extend 404ping however they want
📊 Request history — See what you ran recently, replay it
🧬 Response diffing — Compare staging vs production responses
🎯 Mock server — Spin up mocks from saved responses

Ideas I'm Exploring:

GraphQL support
gRPC testing
WebSocket connections
Request templating

But I'm not rushing. I'd rather ship features that work perfectly than half-bake 10 things.

Try It

If you test APIs and you're tired of:

Postman eating 600MB of RAM
Copying tokens between requests manually
Writing bash scripts to chain API calls
Remembering curl flags

Give 404ping a shot:

git clone https://github.com/toklas495/404ping.git
cd 404ping
npm install && npm run build
404ping --help

⭐ GitHub: github.com/toklas495/404ping

Final Thoughts

v2 was "curl with memory."

Now? 404ping is actually good. It's the tool I reach for first. It's fast, it's powerful, and it gets out of my way.

If you try it and hate something, tell me. If you love it, tell your friends.

And if you have ideas? Open an issue. I'm always looking for the next "why can't it just..." moment.

Happy hunting 🎯

— Nimesh (toklas495)

P.S. — If you're using 404ping for bug bounties or in production, I'd genuinely love to hear your story. Success stories fuel late-night coding sessions.

The Real Story of Account Linking — How I Learned Auth Is a Flow, Not a Login

Nimesh Thakur — Sun, 01 Feb 2026 07:59:22 +0000

Auth is not a login. Auth is a flow. The moment you understand this, everything clicks.

01 — It Started Simple

When I first built authentication, I only had one provider: password login. User signs up with email and password. Done. One table. One row. Life was easy.

Then the product needed Google login. Then GitHub. Then SMS OTP. Then Apple. Suddenly I had five ways for someone to prove they are who they say they are — and I had no idea how to connect them all to the same person.

My first instinct was naive — and almost every developer does this. When someone logs in via Google, I would just look at the email Google gave me. If that email already existed in my users table, return that user. If not, create a new one. No linking. No resolution. Just a simple email lookup.

I thought this was enough. It wasn't.

02 — The Crack in the Wall

I started reading docs — Clerk's account linking guide, Auth0's user account linking strategy. And slowly I realized: my simple email-lookup approach was a security hole.

⚠️ The Attack

An attacker signs up with your email address using a password — but never verifies it. Now your email exists in the system, unverified, with a password hash attached. Later, you try to log in with Google (which has verified your email). If the system just sees "email exists, return user" — the attacker's unverified account is now yours. Account takeover. No notification. No trace.

This is why you can't just match on email. You need to understand who owns what, what is verified, and what needs explicit permission to link. That's when I started redesigning everything.

03 — The New Architecture: Five Tables, Five Responsibilities

Before, I had one big table with email, password, everything crammed together. After reading and thinking, I split it into five clean boundaries. Each table owns exactly one job.

Table	Owns	Why It's Separate
`users`	Who is this person?	Single source of truth for identity
`credentials`	What's their password?	Secrets need their own boundary
`accounts`	What external IDs map to them?	Links Google/GitHub/OTP → one user
`sessions`	Are they logged in now?	Active session state
`refresh_tokens`	Can they stay logged in?	Long-lived auth with rotation

The Full Table Map

Table	Key Columns	Role
`users`	`id`, `email`, `email_verified`	Source of Truth
`credentials`	`user_id`, `password_hash`	Secret Boundary
`accounts`	`provider`, `provider_user_id`, `user_id`	Linking Backbone
`sessions`	`session_token`, `expires_at`, `revoked`	Session Boundary
`refresh_tokens`	`token_hash`, `rotation_count`	Rotation Boundary

💡 Key Insight: Password login does not create an accounts row. Only external providers (Google, GitHub, OTP) do. The credentials table is the password's world. The accounts table is the external world. They never touch each other directly.

04 — Auth Is a Flow, Not a Single Function

This was my biggest mental shift. I used to think of auth as one function: "verify credentials, return user." But when you have multiple providers, auth becomes a state machine. It has steps. It can pause. It can ask for more information. It can fail at different points for different reasons.

I introduced the concept of an AuthFlow — a temporary state that lives between "the user clicked login" and "the session is created."

The Auth Flow — Step by Step

1️⃣  User clicks "Login with Google"
    └─ AuthFlow created with a unique flowId

2️⃣  Provider authenticates
    └─ Google verifies user → returns identity (sub, email, verified?)

3️⃣  resolveAccount() runs
    └─ The brain. Decides: return user? Create? Or pause?

4a ❌ LINK_REQUIRED — Flow pauses
    └─ Email exists with verified password
    └─ Flow saves state, throws error with flowId
    └─ Frontend shows: "Log in with your password first"

4b ✅ OK — Flow completes
    └─ User resolved. AuthFlow deleted. Session created.

5️⃣  linkAccount() — If paused at 4a
    └─ User proves password ownership
    └─ OAuth identity linked. Flow deleted. Session created.

The Code: `authenticate()`

const authenticate = async (providerName, payload, opts) => {
  // Step 1: Get the provider (Google, GitHub, password, etc.)
  const provider = getProvider(providerName);

  // Step 2: Provider gives us an identity
  const identity = await provider.authenticate(payload);

  // Step 3: Resolve — find or create user
  const { type, user } = await opts.Account.resolveAccount(identity);

  // Step 4a: If linking is needed, pause the flow
  if (type === "LINK_REQUIRED") {
    await updateAuthFlow(opts.flowId, {
      status:  "LINK_REQUIRED",
      intent:  "ACCOUNT_LINK",
      identity
    });
    throw Error("Email already linked. Authenticate with password first.");
  }

  // Step 4b: Flow complete — clean up and create session
  await deleteAuthFlow(opts.flowId);
  return await opts.Session.createSession(user, opts);
};

05 — `resolveAccount` — The Brain of It All

This is where the real logic lives. Every login attempt from an external provider goes through here. It's a decision tree, and every branch matters.

The Decision Tree

Is the provider "password"?
├── Yes → Find user by ID. Return OK ✅
└── No ↓

Does provider + provider_user_id exist in accounts table?
├── Yes → Return that user. OK ✅
└── No ↓

Did the provider give us a VERIFIED email?
├── No  → Create new user with just provider_user_id. OK ✅
└── Yes ↓

Does that email already exist in users table?
├── No  → Create new user + account row. OK ✅
└── Yes ↓

⚡ Does this existing user have a password credential?
├── Yes + email IS verified     → LINK_REQUIRED ❌ (pause flow)
├── Yes + email is NOT verified → DELETE that credential. Ghost account.
│                                  Link and continue. OK ✅
└── No password at all          → Safe to link directly. OK ✅

⚡ Why delete the unverified credential? If someone registered with your email but never verified it, that account could belong to an attacker. When Google (or any trusted provider) confirms you own that email, the unverified password account is a ghost. Keeping it means the attacker could still try to recover it. So we remove it.

The Code: `resolveAccount()`

const resolveAccount = async (identity: AuthResult) => {

  // ── Password provider is simple: just find the user ──
  if (identity.provider === "password") {
    const user = await opts.User.findById(identity.user_id);
    return { type: "OK", user };
  }

  // ── Already seen this provider before? Return that user ──
  const existing = await opts.Account
    .getByProviderAndId(identity.provider, identity.provider_user_id);

  if (existing) {
    const user = await opts.User.findById(existing.user_id);
    return { type: "OK", user };
  }

  // ── New provider identity. Check if email is verified ──
  const email    = identity.provider_email;
  const verified = identity.metadata?.provider_email_verified;

  if (email && verified) {
    const existingUser = await opts.User.findByEmail(email);

    if (existingUser) {
      const hasCred = await opts.Cred.getCred(existingUser.id);

      if (hasCred) {
        // ⚡ The critical split
        if (existingUser.email_verified)
          return { type: "LINK_REQUIRED" }; // Must prove password ownership

        // Unverified + has password = ghost account. Delete it.
        await opts.Cred.delCred(hasCred.id);
        await opts.User.setEmailVerified(existingUser.id);
      }

      // Safe to link — no password conflict
      await opts.Account.insertAccount({ ...identity, user_id: existingUser.id });
      return { type: "OK", user: existingUser };
    }
  }

  // ── Nothing matched. Create a brand new user ──
  const newUser = await opts.User.create({
    email: email,
    email_verified: !!verified,
    full_name: identity.metadata.name
  });
  await opts.Account.insertAccount({ ...identity, user_id: newUser.id });
  return { type: "OK", user: newUser };
};

06 — `linkAccount` — Completing the Paused Flow

When resolveAccount returns LINK_REQUIRED, the flow pauses. The frontend shows a password prompt. The user proves they own the existing account. Then linkAccount() picks up where we left off.

const linkAccount = async (flowId, password, opts) => {
  // Retrieve the paused flow
  const flow = await getAuthFlow(flowId);
  if (!flow || flow.status !== "LINK_REQUIRED")
    throw Error("Flow not found or not in LINK_REQUIRED state");

  // Prove password ownership
  const passwordProvider = getProvider("password");
  const primaryIdentity = await passwordProvider.authenticate({
    email: flow.identity.provider_email,
    password
  });

  // Link the OAuth identity to the password user
  const user = await opts.Account.linkAccount(
    primaryIdentity,   // The password user (proven owner)
    flow.identity      // The OAuth identity waiting to link
  );

  // Clean up and create session
  await deleteAuthFlow(flowId);
  return await opts.Session.createSession(user, opts);
};

07 — The Full Picture: Who Does What

Function	Job	Returns
`authenticate()`	Entry point. Orchestrates the entire flow.	Session ✅ or Pause ❌
`resolveAccount()`	Decides what to do with an identity.	`OK` or `LINK_REQUIRED`
`linkAccount()`	Resumes a paused flow after password proof.	Session ✅

08 — What I Took Away

The hardest part wasn't the code. It was understanding why each decision exists.

Why can't I just match on email? Because emails are not proof of ownership — verification is.
Why do I need a separate credentials table? Because secrets need their own boundary.
Why does the flow need to pause? Because sometimes auth requires two steps, not one.

✅ The Three Rules

1. Never trust an unverified email as identity. An attacker can register it first.

2. Separate secrets from identity. Passwords, tokens, and hashes have their own table. Users are just users.

3. Auth is a flow, not a function. It can pause, branch, and resume. Design for that.

Once I saw auth this way — as a state machine with clean boundaries — everything became logical. Each table has a single job. Each function has a single responsibility. The complexity didn't disappear. It just became visible, and visible things are things you can reason about.

If you've been doing the "just check email" approach — it's okay. Now you know. The architecture above is what I moved to, and it handles every edge case I've thrown at it.

The Mirror Trick: Why Knowing Good Habits Changes Nothing

Nimesh Thakur — Mon, 12 Jan 2026 02:19:44 +0000

Everyone says habits decide your future.

Read Atomic Habits. Make a to-do list. Wake up at 5 AM. Meditate. Work deeply. Delete Instagram.

I knew all of this. I read the books. I understood the science.

But I still scrolled for hours. Still sat all day. Still felt my brain turning to fog.

Knowing didn't change anything.

It's like knowing sugar is bad but eating it anyway. The knowledge sits in your head while your hand reaches for the cookie.

Your Brain Isn't Resting When You Think It Is

Here's something nobody explains clearly:

Your brain is like your phone's battery. It drains all day.

When you watch TV while eating dinner, your brain splits in half. 50% goes to the screen. 50% goes to digesting food. Nothing gets full attention.

When you study for 4 hours then "relax" by watching a movie, you're not resting. Your brain is working harder. It's tracking characters, emotions, plot twists. That's not a break. That's just different work.

Same with scrolling after work. You think you're relaxing. But your brain is processing faces, stories, comparisons, dopamine hits. It's sprinting, not resting.

A 12-year-old gets this immediately when you say: "Your brain is always paying for something. Either with focus or with energy."

Why Stopping Never Works

I tried everything.

App blockers. Timers. Deleting social media. Cold turkey.

Nothing stuck.

Here's why: telling your brain "don't do this" is like saying "don't think of a pink elephant."

Now you're thinking of a pink elephant.

The brain doesn't obey force. When you block YouTube, you want YouTube more. When you promise to stop masturbating, the urge grows stronger. When you delete Instagram, you think about Instagram.

Stopping creates tension. Tension creates obsession.

The harder you fight, the louder the urge screams.

The Silent Damage We Ignore

Sitting all day isn't neutral.

Scrolling isn't harmless "me time."

Being idle isn't rest.

Everything costs something.

When you sit to study, then sit to scroll, then sit to watch TV, then sit to work—your body forgets how to move. Your posture collapses. Your energy disappears.

Even "doing nothing" costs energy. Sitting idle while your brain spins with thoughts drains you faster than walking 3 kilometers.

I'm not saying you're bad for doing these things. I'm saying: they're not free. They charge you. And most people don't realize they're paying.

The Shift: Stop Being the Actor

One idea changed everything for me.

It came from a simple concept—don't be the actor in your life. Be the witness.

What does that mean?

When you eat, just eat. Not: eat + scroll + think about work.

When you walk, just walk. Not: walk + make up stories in your head + replay arguments.

When you're angry, just notice: "Oh, I'm angry." Don't dive into the anger. Don't become the anger.

Watch your thoughts like clouds passing. You're the sky, not the cloud.

I know that sounds abstract. Here's the real version:

Stop reacting to every urge immediately. Put a tiny gap between the urge and the action.

That gap is where everything changes.

The Simple Trick: Energy In vs Energy Out

I stopped trying to "be disciplined."

Instead, I started treating my life like a bank account.

Not money. Energy.

Some things deposit energy:

Walking outside
Reading a book that makes me think
15 minutes of silence in the morning
Working out

Some things withdraw energy:

Scrolling for an hour
Watching movies that don't matter
Sitting idle
Masturbating when I'm bored, not because I want to

Nothing is "bad." Nothing is "good."

The only question: Does this give me energy for tomorrow, or does it take it?

The Mirror

I built a simple app. Not a blocker. Not a streak tracker. Just a mirror.

Here's how it works:

You list activities. You mark which ones give energy. Which ones drain it.

Then, whenever you do something, you log it. 50 minutes scrolling YouTube? Log it. 30 minutes walking? Log it.

The app shows your energy balance. Like a bank statement.

That's it.

No shame. No punishment. No streaks to protect.

Just: "Here's what you did today. Here's how much energy you have left."

What Changed Without Trying

After a few days, something weird happened.

I still wanted to scroll. But before opening YouTube, I thought: "This will drain 50 points."

Then I thought: "Walking outside gives me 30 points."

So I walked.

Not because I forced myself. Because I saw it clearly.

I still wanted to masturbate sometimes. But I'd think: "This drains 20 points for nothing."

And the urge just... faded.

I didn't stop it. Awareness stopped it.

I started reading more. Not because reading is "good." Because after 40 minutes of reading, I'd log +100 energy, and my brain liked that feeling.

Meditation increased energy. So I did it more.

Sitting idle drained energy. So I did it less.

Nothing was forced. Everything just shifted.

The Part Nobody Talks About

I still scroll sometimes. I still watch movies. I still sit.

I'm not perfect. I'm not "optimized."

But here's the difference:

Before, I scrolled and felt bad.

Now, I scroll and I see it happening. I know the cost. Sometimes I pay it anyway. But I'm awake.

Before, I'd sit idle and wonder why I felt empty.

Now, I notice: "I'm sitting idle. My energy is draining."

And usually, I get up and walk.

Not because walking is virtuous. Because I can feel the difference.

Conclusion

Habits don't change your life.

Awareness changes your habits.

You don't need more discipline. You don't need more willpower.

You need a mirror.

When you see clearly, you choose better without trying.

That's it. That's the whole trick.

The app I built is called Aware. It's just a mirror. You can try it at aware.404nation.com if you want. Or build your own mirror. Doesn't matter. The tool isn't magic. Seeing clearly is.

The Magic Behind “Login with Google”: How OAuth 2.0 Actually Works

Nimesh Thakur — Sun, 04 Jan 2026 04:10:54 +0000

Introduction: The Magic Login Button

You're on a website. You see "Login with Google" or "Login with GitHub." You click it. Boom — you're logged in. No passwords to remember, no email verification waiting. Just... magic?

But how does this actually work? Let's take a journey together and understand what happens behind that simple button click.

Why Google, GitHub, Facebook Are Used

First question: Why do we always see Google, GitHub, Facebook, X (Twitter), or Microsoft? Why not any random website?

The answer is simple: they have massive user bases. Almost everyone has a Google account. Many developers have GitHub accounts. These companies are famous merchants of identity because they already store information about billions of users.

Think about it — your information is already sitting in Google's servers, tied to your email ID. So why should you sign up on every new website, verify your email again and again? It's exhausting.

That's the problem these providers solve.

Where Our Information Already Lives

Here's the key insight: you're already logged into your browser.

Whether it's Chrome, Firefox, or Safari, you've probably logged into Google or GitHub on your mobile or desktop. Your authentication already exists. You've already proved who you are to these providers.

So new companies thought: "Why not leverage this? Why make users create new accounts when they can just use what they already have?"

And that's how this story begins.

Registering a Website as a Client

Let's pause here. Before any website can offer "Login with Google," they need to register themselves.

Here's what happens:

A company (let's say Canva) goes to Google and says: "Hey, I want to use your authentication service." They register their website as a client with details like:

Application type: Is it a website or a native mobile app?
Name: What's the application called?
URL: Where does it live?
Redirect URI: Where should Google send users back after login?

In return, Google gives them:

client_id: A unique identifier (like a username for the website)
client_secret: A password that authenticates the client to Google

These credentials are crucial. They prove to Google that the request is coming from a legitimate registered client.

Clicking "Login with Provider"

Alright, now we're at the moment you click "Login with Google."

What happens?

The website (client) redirects you to Google's website. This isn't just a simple redirect though. The client sends several important pieces of information along with you.

Authentication and User Consent

You land on Google's page.

First, Google authenticates you. If you're not already logged in, they'll prompt you to enter your email and password.

Once you're authenticated, Google shows you something like:

"Canva.com is asking for your email, name, and profile picture. Allow or deny?"

This is the authorization step. You're deciding what information the client can access.

If you click "Allow," Google prepares to share that information with the client. But what happens at a deeper layer?

What Is Sent During Redirect (High-Level)

When the client redirected you to Google, they sent several parameters. Let me break them down in simple terms:

state: A random token for CSRF protection. It makes every request unique so hackers can't forge requests.
scope: What information does the client want? Email? Name? Profile picture?
client_id: Who is asking? This authenticates the client.
redirect_uri: Where should Google send the user back? Google checks this matches what was registered.
response_type: What kind of response does the client want? Usually authorization_code.
nonce: A random value to prevent replay attacks (we'll explain this later).
code_challenge and code_challenge_method: Extra security (PKCE — we'll get to this).
prompt: Should Google ask for authentication every time, or trust existing sessions?
access_type: Should Google provide a refresh token? (Offline vs online access)

Google checks all these parameters, authenticates you, and asks for your consent.

Authorization Code and State Check

Once you authorize, Google redirects you back to the client's website. But they don't send your information directly.

Instead, they send:

authorization_code: A temporary code
state: The same state token sent earlier

The client's server receives this callback. First thing they do? Check the state token.

If the state matches what they sent earlier, it's a valid request. If not, someone's trying to attack them (CSRF attack).

Now they have an authorization code. But this code alone isn't enough.

Why We Don't Use `response_type=token`

You might wonder: "Why not just send the access token directly?"

Some systems allow response_type=token, where the provider sends the access token immediately in the URL.

This is not secure.

Why? Because the token would be visible in the browser's address bar, in logs, in history. Anyone with access to the browser could steal it.

That's why the secure approach uses authorization_code instead. The real tokens are exchanged server-to-server, hidden from the browser.

Server-to-Server Token Exchange

Now the magic happens behind the scenes.

The client's server makes a POST request to Google's token endpoint. This happens server-to-server, completely hidden from the user's browser.

They send:

grant_type: Set to authorization_code (explains how they're authenticating)
client_id: Their identity
client_secret: Their password (for authentication)
redirect_uri: For validation
code: The authorization code they just received
code_verifier: Extra security (PKCE — hold on)

Google checks everything. If it's all valid, they respond with a JSON containing the real tokens.

PKCE and Why It Exists

Let's pause here. What if a hacker somehow steals the authorization code?

Think about it. The code is sent via redirect in the URL. If someone intercepts it, they could potentially exchange it for tokens.

That's where PKCE (Proof Key for Code Exchange) comes in.

Here's how it works:

Before the redirect, the client generates a random string (32 bytes or more). This is the code_verifier.
They hash it using SHA256. This becomes the code_challenge.
They send the code_challenge and code_challenge_method to Google during the initial redirect.

Google stores this hash.

Later, during the token exchange, the client sends the original code_verifier.
Google hashes it with the same method and compares it to the stored code_challenge.

If they match, the request is valid. If not, someone stole the code.

This makes the flow nearly unbeatable.

Tokens We Receive

If everything checks out, Google responds with JSON containing:

access_token: Used to access user information
refresh_token: Used to get new access tokens when they expire
scope: What information is included
id_token: A JWT token containing user information (only with OpenID Connect)

Many providers like GitHub don't use OpenID Connect, so they might not send an id_token. We'll talk about that in a moment.

ID Token Verification

If we receive an id_token, we need to verify it.

Why? Because it's a JWT (JSON Web Token), and we need to ensure it's actually from Google and hasn't been tampered with.

Here's the process:

Get Google's public JWKS (JSON Web Key Set) URI
Verify the signature on the JWT using the public key
Check the nonce inside the token

Remember that nonce we sent during the initial redirect? It comes back inside the id_token.

We check if the nonce matches what we sent. If it does, this token was created in response to our specific request. This prevents replay attacks — someone can't reuse an old token.

Now we have verified user information.

Getting User Info When OpenID Is Not Used

What if the provider doesn't support OpenID Connect? (Like GitHub)

No problem. We use the access_token.

We make a simple GET request to the provider's user info endpoint with the access token in the Authorization header:

Authorization: Bearer [access_token]

The provider responds with the user's email, name, and other information we requested.

Final Login: User Creation and Session

Now we have everything:

User's email
User's name
Verified information

The server does a few final steps:

Create or get user: Check if this user already exists in our database. If yes, log them in. If no, create a new account.
Account linking: Link this provider account to our user record.
Store tokens: Save the access token and refresh token securely.
Session creation: Create a session for the user.

And... done! The user is logged in.

Closing Thoughts

We've journeyed through a lot:

Why providers like Google exist
How websites register as clients
What happens during redirect
Security measures like state, nonce, and PKCE
Token exchange behind the scenes
Verification and user creation

This flow might seem complex, but each piece exists for a reason — mostly security.

I've touched on many concepts here. There's even more depth to explore (like the full RFC 6749 specification at https://datatracker.ietf.org/doc/rfc6749/), but this gives you the journey from click to login.

The Flow (Simplified)

User                    Client (Canva)              Provider (Google)
  |                          |                              |
  |--Click "Login" --------->|                              |
  |                          |                              |
  |<--Redirect with params---|                              |
  |  (state, scope, client_id, nonce, code_challenge)       |
  |                                                         |
  |--Redirected to Google---------------------------------->|
  |                                                         |
  |<--Authentication & consent screen-----------------------|
  |                                                         |
  |--User approves----------------------------------------->|
  |                                                         |
  |<--Redirect with code & state----------------------------|
  |                                                         |
  |--Return to client-------------------------------------->|
  |                          |                              |
  |                          |--POST request--------------->|
  |                          | (code, client_id,            |
  |                          |  client_secret,              |
  |                          |  code_verifier)              |
  |                          |                              |
  |                          |<--Tokens (access, refresh,   |
  |                          |    id_token)---------------  |
  |                          |                              |
  |                          |--Verify id_token------------>|
  |                          |   or fetch user info         |
  |                          |                              |
  |<--User logged in---------|                              |

JWT Is Not Secure — Until You Understand JWS and JWE

Nimesh Thakur — Sun, 28 Dec 2025 04:19:21 +0000

Start Here

JWTs are not secure by default.

They're fast. Stateless. Powerful. But easy to break if you don't understand what you're actually doing.

Most developers copy-paste jwt.verify(token, secret) and move on. That's where the problems start.

The JOSE Family

JWT stands for JSON Web Token. It's part of JOSE: JSON Object Signing and Encryption.

Two things matter:

JWS (JSON Web Signature) — Signs data. Anyone can read it, but tampering is detectable.

JWE (JSON Web Encryption) — Encrypts data. Only the recipient can read it.

Most JWTs are JWS because you rarely need to hide the payload. You just need proof it hasn't been modified.

What a JWT Actually Looks Like

eyJhbGci...  .  eyJzdWIi...  .  2Xh3n...
   header         payload      signature

Each part is base64url-encoded JSON:

HEADER              PAYLOAD              SIGNATURE
{ "alg": "HS256" }  { "sub": "user_123" }  HMAC(header + payload)

Visual breakdown:

┌─────────────┐
│   HEADER    │ → Algorithm + metadata
├─────────────┤
│   PAYLOAD   │ → Your claims (readable!)
├─────────────┤
│  SIGNATURE  │ → Proof of integrity
└─────────────┘

The payload is NOT encrypted. Base64 is encoding, not encryption. Anyone can decode and read it.

atob("eyJzdWIiOiJ1c2VyXzEyMyJ9")
// {"sub":"user_123"}

The signature is what protects you. It proves the token came from someone with the key and hasn't been modified.

The Header

{
  "alg": "HS256",
  "kid": "f47ac10b-58cc-4372-a567-0e02b2c3d479"
}

alg — How it's signed (HS256, RS256, ES256)

kid — Which key was used (UUID only, never a path or URL)

jku — URL to fetch keys (never trust this from the token)

Rule: Don't make security decisions based on header values. Attackers control headers too.

The Payload

{
  "sub": "user_5839",
  "exp": 1640995200,
  "iss": "https://auth.yourapp.com",
  "aud": "https://api.yourapp.com"
}

exp — Expiration (mandatory)

iss — Who issued it

aud — Who it's for

jti — Unique ID (for logout/blacklisting)

Don't put secrets here. Passwords, API keys, SSNs—none of that belongs in a JWT.

When JWE Makes Sense

JWE encrypts the payload:

header.encrypted_key.iv.ciphertext.tag

Use it when:

Tokens pass through untrusted intermediaries
Compliance requires encryption at rest

Skip it when:

You're using HTTPS (already encrypted in transit)
You control both issuer and verifier

Most systems don't need JWE.

Where Security Breaks

Algorithm Confusion

Token says "alg": "HS256" but your server expects RS256. If your code doesn't enforce the algorithm, attackers can forge tokens.

// Vulnerable
const decoded = jwt.verify(token, publicKey);

The "none" Algorithm

Token with "alg": "none" and no signature. Some libraries accept this.

eyJhbGciOiJub25lIn0.eyJzdWIiOiJhZG1pbiJ9.

Trusting Headers

Using kid from the token to load keys:

{ "kid": "../../etc/passwd" }
{ "kid": "http://attacker.com/keys" }

If you do loadKey(header.kid) without validation, you're in trouble.

Skipping Claim Validation

Verifying the signature isn't enough. You must validate:

Algorithm matches what you expect
Token hasn't expired
Issuer is correct
Audience is correct

Fetching Keys from Untrusted URLs

Token's jku points to https://evil.com/keys. Your server fetches keys from there, "verifies" the attacker's token.

How to Verify Correctly

jwt.verify(token, key, {
  algorithms: ['RS256'],              // Hardcode this
  issuer: 'https://auth.yourapp.com', // Hardcode this
  audience: 'https://api.yourapp.com', // Hardcode this
  maxAge: '30m'
});

Rules:

Explicitly set allowed algorithms
Validate issuer and audience
Never trust jku from the token—configure JWKS URL server-side
Use UUIDs for kid, not paths or URLs
Keep access tokens short (15-30 min)
Use longer refresh tokens with revocation support

The Mental Model

A JWT is a signed statement.

The signature proves integrity and authenticity. It doesn't prove the token should be accepted.

You decide that by validating the claims.

Final Thought

Tools don't fail. Understanding fails.

Most JWT vulnerabilities come from trusting input you shouldn't trust or skipping validation you should enforce.

Configure strictly. Validate everything. Never assume the library handles security for you.

The difference between safe and broken is understanding what the signature actually proves.

Reference: RFC 7515 (JWS), RFC 7516 (JWE), RFC 7519 (JWT)

When Sleep Became a Problem

Nimesh Thakur — Thu, 25 Dec 2025 09:32:09 +0000

Sleep was a nightmare for me once.

Not the kind where you wake up scared.

The kind where you're scared to fall asleep.

This is what happened. And what I learned.

It Started in 9th Class

I don't know what triggered it.

I was just... tense. Worried about nothing specific. My mind felt busy even when idle.

Then one night, something strange happened.

What It Felt Like

I fell asleep. But only my body did.

What happened:

My eyes stayed open
My ears kept working
My mind was fully awake
My body was completely frozen

I could see my room. Hear everything around me. But I couldn't move. Not my hand. Not my legs. Nothing.

My brain tried to make sense of it. When your mind can't explain something, it fills in the gaps. Creates shapes. Presences. Things that feel real because you're seeing them with open eyes.

I thought: "This is a dream."

Then I realized: "This isn't a dream."

That was the scary part.

The Pattern (9th to 12th Class)

This became my daily routine:

At Night:

First sleep: 2-3 minutes
Paralysis would happen
After that: normal sleep

Afternoon Naps:

Worse
Lasted 2 to 15 minutes
Same experience every time

The Hardest Part:

Most people don't know when they fall asleep.

They just... disappear into it.

I knew. Every single time.

It felt like:

Going deeper and deeper into my own mind
Like something drilling inward
Then suddenly: silence
Then: frozen

When Awareness Became Too Much

During army training in Uttarakhand, I started noticing something.

I watched how others slept:

They lay down
They disappeared
They woke up

Simple. No drama.

My Experience Was Different:

I was aware of everything:

Going into sleep
Being in sleep
Coming out of sleep
Even my own breathing

I could hear myself snore. Feel my breathing stop for a second. Then air rushing through my mouth with sound.

I researched it. Found out it's normal:

Muscles relax during sleep
They block airflow briefly
You push air through
Creates sound

But being aware of everything while sleeping isn't peaceful.

It's like standing at a door instead of walking through it.

What I Figured Out

The problem wasn't sleep.

The problem was my mind not knowing how to let go.

Normal sleep = trust and let go

My sleep = watch everything, stay alert

I couldn't rest because I wouldn't stop observing.

What Actually Helped

After 12th, I started reading. Philosophy. Meditation. Yoga.

Not to "fix" sleep.

To understand what was happening.

What I Learned:

How sleep works:

Brain paralyzes your body during sleep
This is normal
Prevents you from acting out dreams

What wasn't normal:

My awareness staying on during paralysis
Fear keeping me alert
Creating a loop

The real issue:

Stressed mind
Too much pressure
Fear feeding more fear

What Changed:

Meditation taught me something simple:

How to stay calm while being aware.

Not fighting awareness.

Not fighting fear.

Just... being okay with both.

The result:

Less fear = fewer episodes
Less tension = easier sleep
Eventually: it just faded

No dramatic ending. Just gradual peace.

Looking Back

Those experiences weren't my enemy.

They were signals.

Signals that:

My mind was under pressure
I was holding too tight
I didn't trust rest

I didn't beat sleep by fighting it.

I understood what was really happening.

What This Taught Me

Some problems don't go away when you force them.

They go away when you understand them.

The difference:

Fighting vs. understanding
Controlling vs. allowing
Staying tense vs. learning to release

This applies to more than just sleep.

Today

Sleep is normal now.

Not perfect. Just normal.

And normal feels like a gift.

One Last Thing

We live in a world that values control.

Productivity. Optimization. Awareness of everything.

But sometimes the answer isn't more control.

Sometimes it's less.

Rest isn't something you force.

It's something you allow.

The deepest healing begins not when fear ends —

but when understanding begins.

This is a personal experience, not medical advice. If you're experiencing something similar, talk to a professional.

The Day I Stopped Chasing Everything and Found My One Thing

Nimesh Thakur — Sun, 21 Dec 2025 02:49:00 +0000

So let me tell you a story. It's mine, but honestly, it might be yours too.

When I was a kid, I used to draw cars and bikes all day. Like, REALLY draw them. Every detail. The curves, the engines, the wheels. I'd sit there for hours just sketching, and I thought to myself, "Yeah, this is it. I'm going to be a car designer." That was the plan. That was my passion. Or so I thought.

Then 9th class happened.

I don't know what got into me, but suddenly I was obsessed with the army. I'd watch these videos of Para Commandos and think, "Forget cars, man. I want to do THIS." Me and my best friend, we got serious about it. We trained for 4 months straight. Physical training, studying, the whole deal. We were ready for NDA. We were PUMPED.

And then... we didn't get selected. Neither of us.

That hurt. But we didn't give up completely. We figured, okay, let's do BTech. At least then we'll have a shot at CDS or technical entry later. We chose Cyber Security as our specialization. Made sense, right? Technical degree, still a path to the army if we wanted it.

But here's where things get weird.

I'm sitting there in this Cyber Security program, and I'm thinking, "If I'm learning this stuff anyway, why not actually TRY this field?" So I decided to pick up coding. First language? Java. And I picked Java for the dumbest reason possible - I didn't know how to set up VSCode, Python, or C++. But Java? Java just... worked. First try. So I went with it.

I dove into Java. Learned data structures and algorithms. Did all the problems. And honestly? I didn't enjoy it. At all. But I kept going because, you know, that's what you're supposed to do, right?

Then I tried web development. That was a bit better. Then app development - and oh man, I thought THIS was it. This was my calling. I could see myself building apps, creating cool stuff. I was so excited.

Until I tried to open Android Studio on my 4GB Dell Inspiron laptop.

The laptop literally couldn't handle it. It was like watching a car trying to fly. Just... no. Dream over.

So I moved on to computer networks. And you know what? I actually enjoyed this one. Learning about Wireshark, tcpdump, tracing packets, monitoring network traffic - it was interesting. I was learning real stuff that made sense.

Then I discovered binary pentesting. I read this book called "Hacker: The Art of Exploitation" and my mind was blown. Stack, heap, buffer overflow, format string vulnerabilities, shellcode - all this deep technical stuff that most people never touch. I was hooked.

And that led me to web pentesting. THIS, I thought, was my passion. Finally. I'd found it.

I went deep. Like, REALLY deep. I was reading books non-stop - I must have read 60+ books during this whole journey. Everything from hacking to web security to penetration testing. I learned Burp Suite, PortSwigger Academy, HackTheBox, Caido, subfinder, amass, and probably 500 other tools. GitHub became my second home because I was git cloning new tools every single day. I got so familiar with Git that I could probably do it in my sleep.

I even started building my own tools. I dropped JavaScript and went all in on Python and Bash for scripting. I became really good at it. Like, damn good. I could automate anything, build anything. I felt powerful.

Then came bug bounty hunting.

I loved the idea. No degree required, no certification needed - just find bugs in real systems and get paid. It was perfect. Or so I thought.

I spent 6 to 7 months grinding. And I mean GRINDING. I found 50+ bugs. Fifty bugs. You know how many were accepted? One. Just one. A rate limit bypass in Yatra.com.

They paid me $50.

Fifty dollars for half a year of work.

I burned out. Completely. I was exhausted, frustrated, and questioning everything. But during that burnout, I had this idea. What if there was one platform where every hacker could share resources, tools, ideas, strategies - everything in one place? A single platform for the entire community.

I didn't know backend development, but I thought, "Why not give it a shot?" I called my friend who knew frontend, and I told him I'd handle the backend. So I learned backend development. I read books about Node.js, design patterns, data structures - all of it. And I actually built the application.

Then I did something bold. I reached out to some of the biggest names in hacking - Samcurry, Nahamsec, Gareth Heyes - probably messaged around 500 hackers in total. I wanted to know if this idea could work.

Out of 500, one person replied. Gareth Heyes.

He said, "It's impossible to get all hackers to contribute to one single platform."

And that was it. The dream died right there.

But here's the thing - while building that backend, I noticed something. Something I couldn't ignore.

I LOVED building authentication and authorization systems. Not the entire backend. Just auth. The flows, the security models, the system design, all those tiny intricate details that most people don't even think about. I could spend hours designing auth flows and not even notice the time passing. My friend, the one doing frontend? He didn't get it. He couldn't understand why I was so obsessed with these details.

But I did. I saw it all clearly.

And that's when it hit me.

You know how in nature, every animal has ONE thing they're great at? A lion has its teeth. An eagle has its claws. An elephant has its trunk. A peacock has its tail. Nobody has everything. Each creature has one unique strength.

Even if you look at gods - Shiva is the destroyer, Brahma is the creator, Vishnu is the preserver. Each one has their role. Their ONE thing.

Bruce Lee said something that stuck with me: "I don't fear the man who has practiced 10,000 kicks. I fear the man who has practiced one kick 10,000 times."

And I realized - I'd been trying to practice 10,000 kicks this whole time.

Look at my journey: Car designer → Army → Java → DSA → Web Development → App Development → Networks → Binary Pentesting → Web Pentesting → Bug Bounty → Backend Development → Authentication & Authorization.

I kept compressing. Narrowing down. Moving toward something, not away from things. And I didn't even realize it until that moment.

But here's where the real battle started - the battle between my mind and my heart.

My mind kept telling me: "Bro, focus on DSA. Learn the full backend stack. Be practical. Get any job. Everyone says you need to know everything."

But my heart was saying: "You light up when you work on auth. That's your signal."

And I kept thinking about Arjun from the Mahabharata. You know that story, right? Where Dronacharya asks all his students what they see when aiming at a bird on a tree. Everyone describes the whole scene - the bird, the tree, the branches, the sky.

But Arjun? Arjun says, "I see only the eye of the bird."

That's when I made my decision.

Authentication and Authorization is my bird's eye. That's my one thing. I don't need to be a full-stack developer. I don't need to master DevOps, or frontend frameworks, or database administration. I need to go so deep into this ONE thing that when people think about auth, they think of me.

So that's what I'm doing now. I'm practicing authentication and authorization every single day. I'm aiming for IAM roles, AuthN/AuthZ specialist positions. Is it risky? Maybe. Is it conventional? Not at all. But here's what I know for sure:

The world doesn't need another developer who knows a little bit of everything. The world needs people who go DEEP. Who become THE person for one specific thing.

And that's the earth fact nobody tells you - nobody masters everything. Nobody CAN master everything. And that's not a weakness. That's actually your freedom. Freedom to say "this is my thing" and ignore all the noise telling you to learn more, do more, be more.

So if you're reading this and you're jumping between technologies, feeling scattered, wondering if you should add "just one more skill" to your resume... stop for a second.

Ask yourself: What do you keep coming back to? What makes you lose track of time? What do your friends not understand but you see with complete clarity?

That's your signal. That's your one thing.

Go practice that one kick 10,000 times.

Trust me, it's worth it.

What's your one thing? I'd genuinely love to hear about it in the comments.

I Crashed My Server with Promise.all() - Here's How I Built a 121 RPS Fuzzer Instead

Nimesh Thakur — Sun, 14 Dec 2025 04:21:52 +0000

The Journey of Making 404fuzz Blazingly Fast ⚡

When I started building 404fuzz, I had one goal: make it fast. Really fast. But I quickly learned that speed in Node.js isn't just about throwing more requests at a server. It's about understanding how Node.js actually works.

Let me take you on the journey from my first "obvious" solution to a fuzzer that achieves 121 RPS on modest hardware.

Chapter 1: The Promise.all() Trap 🪤

My First Thought

"Easy! I'll just load all my wordlist paths and fire them all at once with Promise.all()!"

// My first naive approach
const wordlist = ['admin', 'backup', 'config', ...]; // 10,000 paths
const promises = wordlist.map(path => fetch(`${target}/${path}`));
await Promise.all(promises); // Fire everything!

The Brutal Reality

This crashed everything. My laptop froze. The target server probably hated me. What went wrong?

Here's what I learned: Promise.all() is NOT parallel execution.

Understanding Node.js: Concurrent, Not Parallel 🔄

Let me explain with a diagram:

┌─────────────────────────────────────────────────┐
│          Node.js Single Thread                  │
├─────────────────────────────────────────────────┤
│                                                 │
│  Your Code (Asynchronous)                        │
│         ↓                                       │
│  Event Demultiplexer (Receives all events)     │
│         ↓                                       │
│  Event Queue [Event1, Event2, Event3, ...]     │
│         ↓                                       │
│  Event Loop (while(queue.length > 0))          │
│    ├─ Takes Event1                             │
│    ├─ Executes Callback                        │
│    ├─ Returns immediately (non-blocking!)      │
│    └─ Takes Event2...                          │
│                                                 │
└─────────────────────────────────────────────────┘

Key Insight: Node.js is concurrent (non-blocking), not parallel (multiple things at once).

When you do Promise.all() with 10,000 requests:

❌ You don't get 10,000 parallel threads
❌ You DO get 10,000 open connections
❌ You DO consume massive memory
❌ You DO overwhelm both your system and the target

Result: System crash, memory exhaustion, or you become an accidental DDoS attacker.

Chapter 2: The Queue Model - Controlled Chaos 🎯

The Better Approach

I needed bounded concurrency - control how many requests run at once, queue the rest.

┌────────────────────────────────────────┐
│      Wordlist (10,000 paths)           │
└────────────┬───────────────────────────┘
             ↓
┌────────────────────────────────────────┐
│         Request Queue                  │
│  [req1, req2, req3, req4, req5, ...]   │
└────────────┬───────────────────────────┘
             ↓
┌────────────────────────────────────────┐
│    Concurrency Limit (e.g., 50)       │
│                                        │
│  [Active1] [Active2] ... [Active50]   │
│      ↓          ↓            ↓         │
│   Response  Response     Response      │
│      ↓          ↓            ↓         │
│  Next from queue (req51)               │
└────────────────────────────────────────┘

The Implementation

class RequestQueue {
  constructor(concurrency = 50) {
    this.concurrency = concurrency;
    this.running = 0;
    this.queue = [];
  }

  async add(task) {
    // If we're at limit, queue it
    if (this.running >= this.concurrency) {
      await new Promise(resolve => this.queue.push(resolve));
    }

    this.running++;
    try {
      return await task();
    } finally {
      this.running--;
      // Release next queued task
      if (this.queue.length > 0) {
        const resolve = this.queue.shift();
        resolve();
      }
    }
  }
}

The Results

✅ Memory stays stable
✅ Target server doesn't die
✅ Predictable resource usage
✅ You can tune with -t flag (concurrency level)

But I wanted MORE speed. Time for the next level.

Chapter 3: Multi-Core Power - The Cluster Model 💪

The Problem

Node.js is single-threaded. My i5 processor has 8 cores. I'm using only 12.5% of my CPU!

The Solution: Node.js Cluster Module

┌─────────────────────────────────────────────────┐
│            Primary Process (Master)             │
│                                                 │
│  - Loads wordlist                               │
│  - Splits work among workers                    │
│  - Collects results                             │
└────────────┬───────────────────────┬────────────┘
             │                       │
      ┌──────┴──────┐         ┌──────┴──────┐
      ↓             ↓         ↓             ↓
┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐
│ Worker 1 │  │ Worker 2 │  │ Worker 3 │  │ Worker 4 │
│          │  │          │  │          │  │          │
│  Queue   │  │  Queue   │  │  Queue   │  │  Queue   │
│  Model   │  │  Model   │  │  Model   │  │  Model   │
│  (-t 10) │  │  (-t 10) │  │  (-t 10) │  │  (-t 10) │
└──────────┘  └──────────┘  └──────────┘  └──────────┘
     ↓             ↓              ↓             ↓
   Target       Target         Target        Target

The Implementation

// Primary process
if (cluster.isPrimary) {
  const numWorkers = getCoreCount(options.cores); // -c flag
  const workload = splitWordlist(wordlist, numWorkers);

  for (let i = 0; i < numWorkers; i++) {
    const worker = cluster.fork();
    worker.send({ paths: workload[i], concurrency: options.threads });
  }
}

// Worker process
if (cluster.isWorker) {
  process.on('message', async ({ paths, concurrency }) => {
    const queue = new RequestQueue(concurrency);
    for (const path of paths) {
      await queue.add(() => fuzzPath(path));
    }
  });
}

Chapter 4: The Sweet Spot - Balancing Act ⚖️

Here's where it gets interesting. More workers ≠ More speed

The Complexity

You're now balancing TWO variables:

Clusters (-c): Number of worker processes
Concurrency (-t): Requests per worker

What I Discovered

Configuration              RPS     Why?
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-c 8  -t 2                 ~65     Too much IPC overhead
-c 4  -t 5                 ~95     Better balance
-c 2  -t 10               ~121     SWEET SPOT! ⭐
-c 1  -t 20                ~85     Bottlenecked by single process
-c all -t 20              ~70     IPC kills performance

The Pattern: Fewer workers + higher concurrency = faster!

Why?

Fewer Workers (e.g., -c 2):
┌──────────────┐
│   Worker 1   │───┐
│   -t 10      │   │  Less communication
│   (10 reqs)  │   ├─> overhead between
└──────────────┘   │  processes
                   │
┌──────────────┐   │
│   Worker 2   │───┘
│   -t 10      │
│   (10 reqs)  │
└──────────────┘

More Workers (e.g., -c 8):
┌────────┐┌────────┐┌────────┐┌────────┐
│Worker 1││Worker 2││Worker 3││Worker 4│
│ -t 2   ││ -t 2   ││ -t 2   ││ -t 2   │
└───┬────┘└───┬────┘└───┬────┘└───┬────┘
    │         │         │         │
    └─────────┴─────────┴─────────┘
         High IPC (Inter-Process
         Communication) overhead!

Chapter 5: Putting It All Together 🎯

The Final Architecture

┌───────────────────────────────────────────────┐
│         404fuzz Primary Process                │
│                                                │
│  1. Load wordlist                              │
│  2. Parse target & options                     │
│  3. Calculate optimal worker count (-c flag)   │
│  4. Split wordlist into chunks                 │
│  5. Spawn workers                              │
└────────────┬──────────────────────────────────┘
             │
      ┌──────┴──────┐
      ↓             ↓
┌─────────────┐  ┌─────────────┐
│  Worker 1   │  │  Worker 2   │
│             │  │             │
│  ┌────────┐ │  │  ┌────────┐ │
│  │ Queue  │ │  │  │ Queue  │ │
│  │ Model  │ │  │  │ Model  │ │
│  │ (-t N) │ │  │  │ (-t N) │ │
│  └───┬────┘ │  │  └───┬────┘ │
│      ↓      │  │      ↓      │
│   [10 reqs] │  │   [10 reqs] │
└──────┬──────┘  └──────┬──────┘
       ↓                ↓
     Target          Target

Usage Examples

# Fast & balanced (recommended)
404fuzz  https://target.com -w wordlist.txt -c 2 -t 10

# Maximum concurrency, fewer workers
404fuzz  https://target.com -w wordlist.txt -c half -t 20

# Use all cores (not always faster!)
404fuzz  https://target.com -w wordlist.txt -c all -t 5

# Single core for testing
404fuzz  https://target.com -w wordlist.txt -c 1 -t 50

The Results 📊

Hardware: Dell 7290, i5 8th Gen, 8GB RAM, 256GB SSD

Performance:

Peak RPS: 121 requests/second
Memory usage: Stable (~200-300MB)
CPU usage: Efficient (50-60% on 2 cores)

Comparison:

Approach                    RPS    Memory   Crashed?
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Promise.all() (naive)       N/A    >2GB     YES 💥
Queue only (single core)    ~45    ~150MB   No
Queue + Cluster (optimal)   ~121   ~250MB   No ✅

Key Takeaways 🎓

Node.js is concurrent, not parallel - Understanding the event loop is crucial
Unbounded concurrency is dangerous - Always implement a queue with limits
More workers ≠ better performance - IPC overhead is real
Sweet spot exists - Fewer workers + higher concurrency often wins
Experimentation is key - Every system is different, test your configs!

Try 404fuzz Yourself

# Clone the repository
git clone https://github.com/toklas495/404fuzz.git
cd 404fuzz

# Install dependencies
npm install

# Build and link globally
npm run build

# Verify installation
404fuzz

# Start fuzzing with recommended settings
404fuzz https://target.com/FUZZ -w /path/to/wordlist.txt -c 2 -t 10

⭐ GitHub Repository

What's Next?

Now that we've achieved speed, the next step is adding intelligence - making 404fuzz learn from responses, adapt its strategies, and discover paths smarter, not just faster.

But that's a story for another blog post. 😉

Built with ❤️ and lots of trial & error. If this helped you understand Node.js concurrency better, drop a ⭐ on the repo!

Building 404fuzz: A Multi-Core Fuzzer That Never Gets Tired

Nimesh Thakur — Sat, 06 Dec 2025 06:35:44 +0000

Most people think fuzzers are just “tools that send fast requests.”

That’s true.

But building a fuzzer that is fast, memory-safe, multi-core, stream-based, and developer-friendly is a completely different challenge.

This is the story of how 404fuzz was born — not from copying ffuf — but from real hacking pain, real performance problems, and real engineering trade-offs.

🧠 The Problem That Started Everything

As a bug bounty hunter, I faced the same issue again and again:

📂 Huge wordlists (millions of lines)
🐌 Tools eating RAM
💥 Crashes on large scans
🧠 Too many duplicate responses
⚠️ Rate-limit (429) killing scans
🧱 Tools that were either:
- too dumb
- or too heavy like a scanner

I didn’t want:

Another Burp
Another Nuclei
Another slow Python fuzzer

I wanted:

✅ A dumb but insanely fast fuzzer, with just enough intelligence to save my time.

That’s how 404fuzz started.

🐜 Philosophy of 404fuzz

“Like an ant, 404fuzz never gets tired.”

404fuzz follows only three core rules:

⚡ Speed is non-negotiable
🧩 Memory safety comes first
🎯 Hunter decides what’s interesting — not the tool

This means:

❌ No heavy “AI logic”
❌ No scanning rules
❌ No auto-vulnerability detection
✅ Just pure high-performance fuzzing

⚙️ How 404fuzz Actually Works (Internals)

✅ 1. Streaming Wordlist (No Memory Bombs)

Instead of loading the entire wordlist into memory:

export async function* streamWordlist(path, workerId, totalWorkers) {
  for await (const line of rl) {
    if (index % totalWorkers === workerId) {
      yield payload;
    }
  }
}

This means:

You can fuzz with million-line wordlists
RAM stays stable
Each worker gets its own shard

✅ 2. Concurrency Without Promise.all Memory Leaks

Instead of doing this ❌:

await Promise.all(requests)

404fuzz uses a real queue-based concurrency model:

class FuzzQueue {
  constructor(concurrency = 500) {
    this.running = 0;
    this.queue = [];
  }

  async add(task) {
    if (this.running >= this.concurrency) {
      await new Promise(resolve => this.queue.push(resolve));
    }
    this.running++;
    try {
      return await task();
    } finally {
      this.running--;
      if (this.queue.length) this.queue.shift()();
    }
  }
}

This gives:

✅ Stable memory
✅ Controlled throughput
✅ No unhandled promise explosions

✅ 3. Multi-Core Parallelism with Cluster

404fuzz doesn’t fake performance with async only.

It uses:

Node.js cluster
One worker per CPU core
Automatic wordlist sharding
Real RPS aggregation

This is why 404fuzz scales like ffuf.

✅ 4. Live Dashboard (Like htop, but for Fuzzing)

Real-time:

RPS
Progress
ETA
Error rates
Worker stats

No log spam.
No blind fuzzing.

🎯 What 404fuzz Is (And Is Not)

✅ IS:

A fast fuzzer
A research tool
A behavioral explorer
A payload testing engine

❌ IS NOT:

A vulnerability scanner
A Burp replacement
A rule-based exploitation engine

404fuzz will always stay a fuzzer first.

🧠 The Real Pain: 70% Duplicate Responses

Every hunter knows this pain:

You fuzz 100,000 payloads…

And you get:

Same 404 page again and again
Same JSON error template
Same WAF response
Same backend validation message

📉 70–90% results are noise

Filtering such results manually is painful and slow.

✅ The Next Smart Step (Not “AI Brain”)

I deliberately decided NOT to make 404fuzz a scanner.

Instead, the near-future focus is only on:

🧠 1. Smart Response Deduplication

Merge identical backend behaviors
Group payloads by same response signature
Show:
- ✅ unique behaviors
- 📊 how many payloads hit the same logic

This reduces:

Noise
Output size
Mental fatigue

🛑 2. Simple 429 (Rate-Limit) Handling

No AI.
No guessing.

Just:

Detect 429
Respect Retry-After
Delay intelligently
Continue scan safely

🧑‍🤝‍🧑 Why I’m Writing This: Open Source Collaboration

404fuzz is fully open source:

👉 https://github.com/toklas495/404fuzz

This project is for:

Bug bounty hunters
Security engineers
Node.js devs
Tool builders
Performance nerds

You can contribute in many ways:

✅ Core engine improvements
✅ New output modes
✅ Deduplication logic
✅ Rate-limit handling
✅ Dashboard features
✅ Docs & testing
✅ Bug fixes
✅ Performance benchmarks

This is not a “solo ego tool.”
I want this to become a community-powered fuzzer.

🐜 Final Words

404fuzz exists because:

We needed speed without stupidity
We needed simplicity without weakness
We needed a tool that respects:
- developers
- hunters
- and system performance

If you believe:

Fuzzing should stay fast
Tools should stay hackable
Open source should stay collaborative

Then I invite you to build this with me.

⭐ Star
🐛 Report issues
💡 Propose features
🔧 Send PRs

👉 https://github.com/toklas495/404fuzz

404ping v2 — The API Testing CLI That Went From Side-Project to Beast Mode 💥

Nimesh Thakur — Sat, 29 Nov 2025 12:10:16 +0000

curl + Postman + brain = 404ping

When I built 404ping v0.0.1, it was a tiny experiment.
I just wanted a simple CLI tool that let me test APIs quickly — without opening Postman or remembering curl flags.

That first version could only:

Send simple HTTP requests
Store a few variables
Handle basic collections

That’s it.
But the response from developers and bug hunters was insane — people loved the speed & simplicity.
So I went back to the lab. And now, after countless commits, refactors, and caffeine, 404ping v2 is here.

And it’s not an upgrade…
It’s a transformation.

🚀 Introducing 404ping v2

Lightweight API Testing CLI — curl with a brain 🧠

No GUI. No accounts. No cloud sync.
Just pure, fast, developer-focused power.

npm install
npm run build
404ping request https://api.example.com

✨ New Version Highlights

Feature	curl	Postman	404ping
Lightweight CLI	✅	❌	✅
GUI Required	❌	✅	❌
Variables	❌	✅	✅ (global & scoped)
Collections	❌	✅	✅ (CLI-based)
Save & reuse requests	❌	✅	✅
TLS / SSL inspection	⚠️	✅	✅
Debug connection / TLS / timing	❌	⚠️	✅
Output modes	⚠️	⚠️	🔥
Secure by default	⚠️	⚠️	🔐

🧨 What’s New in v2 (Massive Upgrade)

🔄 Smart Saved Requests

Save requests with just one flag:

404ping request {{host}}/api/login -X POST \
-d '{"email":"{{email}}"}' \
--save myapp.login

Run anytime:

404ping run myapp:login

Override & save:

404ping run myapp:login -u https://staging.api.com/login --save

🧬 Variable System: global + collection

404ping set host:https://api.myapp.com token:abc123
404ping request {{host}}/users/me -H "Authorization: Bearer {{token}}"

Scoped:

404ping set myapp.token:xyz myapp.host:https://api.myapp.com
404ping request {{myapp.host}}/users

📁 Collections — Project API management like Postman, but CLI

404ping collection create myapp
404ping collection save myapp login -X POST {{host}}/auth/login -d '{"email":"{{email}}"}'
404ping collection show myapp

🎯 Advanced Output Modes

404ping request https://api.example.com --info        # Full analysis mode
404ping request https://api.example.com --connection # Network info
404ping request https://api.example.com --tls        # SSL certificate details
404ping request https://api.example.com --debug      # Everything

🔐 Security-focused

✔ SSL verify by default
✔ TLS breakdown
✔ Input validation
✔ Path traversal protection
✔ Explains failure reasons

🧪 Real-World Workflow Example

404ping set host:https://api.myapp.com token:abc123
404ping collection create myapp

404ping request {{host}}/auth/login -X POST \
-d '{"email":"dev@myapp.com","password":"hello"}' \
--save myapp.login

404ping run myapp:login --info
404ping set token:eyJhbGc...         # update token after login
404ping run myapp:profile --connection

🤝 Why I Built It (Personal Note)

I created 404ping because:

➡ Postman is too heavy
➡ curl is too raw & hard to reuse
➡ I wanted something fast, scriptable, hacker-friendly

Now it has:

🔥 Collections
🔥 Variables
🔥 Saved requests
🔥 TLS inspecting
🔥 Debug view
🔥 Secure defaults
🔥 And zero GUI

This is my tribute to terminal developers who prefer typing over clicking.

💡 Who Should Use 404ping?

👨‍💻 Backend developers
🛡 Bug bounty hunters
🧪 QA testers
⚙ DevOps / CI pipelines
🖥 Terminal lovers
🌎 Anyone tired of Postman’s 600MB RAM usage

🧠 Future Roadmap

📦 Export / Import Postman Collections
🔗 Request chaining (use previous responses)
📄 .env support
🧪 Assertions for automated tests

📥 Installation

git clone https://github.com/toklas495/404ping.git
cd 404ping
npm install
npm run build

🔥 Final Words

From a small v0.0.1 idea
to a production-ready API testing CLI—
404ping became something I am proud of.

If you’re tired of fighting Postman or writing curl novels,
give 404ping v2 a try.

⭐ Star it if you like it
🛠 Contribute ideas
🐞 Report issues
💬 PRs welcome

👉 GitHub: github.com/toklas495/404ping

🎤 Call to action

If this tool helps you:

⭐ Give a star on GitHub
🎭 Share with dev friends
🔧 Try your first collection today