Forem: WI$DOM

Everything gRPC (Part 1)

WI$DOM — Tue, 07 Apr 2026 09:26:51 +0000

When people (Devs) first hear about gRPC, the usual description is that it’s a high-performance RPC framework built on top of HTTP/2, using Protocol Buffers.

That’s accurate.

But it doesn’t really help you understand anything.

Because the real confusion doesn’t come from what gRPC is, it comes from how it actually behaves when you’re building with it.

The moment you open a .proto file for the first time, it feels unfamiliar. You’re defining services, messages, fields with numbers attached to them. It doesn’t look like the typical request-response structure you’re used to with REST.

And that’s where the shift begins.

Instead of thinking in terms of URLs and JSON payloads, gRPC asks you to think in terms of contracts.

The .proto file is not just a schema. It’s more like an agreement between two systems. It defines what can be said, how it should be said, and in what structure. Before any communication happens, both sides already understand the language.

Those numbers you see attached to fields are not random. They exist so that the message can be serialized efficiently. The system doesn’t care about the field names as much as it cares about those tags. That’s part of what makes it fast, but also part of what makes it feel strange at first.

Then comes the generated code.

At this point, it can feel like magic. You write a .proto file, and suddenly you have client and server code generated for you. Functions appear, request and response objects are already defined, and you’re expected to just use them.

But what’s really happening is simple.

The .proto file defines the contract.
The generated code enforces that contract.

Now when a client wants to talk to a server, it doesn’t “construct” a request manually like in REST. It simply calls a function, almost like calling a local method. Under the hood, gRPC takes that function call, serializes the data using Protocol Buffers, sends it over HTTP/2, and reconstructs it on the server side.

So instead of thinking:
“I’m sending an HTTP request”

It’s more accurate to think:
“I’m calling a function that happens to exist on another machine.”

That mental shift is where things start to make sense.

At first, everything feels abstract. The .proto file, the generated code, the client and server setup. It can feel like you’re just wiring things together without understanding the flow.

But once you build a few small examples, the pattern becomes clearer.

The client calls a method.
The method follows a contract.
The contract was defined before anything was built.

And everything else is just implementation detail.

That’s the entry point into understanding gRPC.

Not just what it is, but how to think with it.

Follow for Part 2 -> streaming (where it gets really interesting).

I Built an AI Agent to End Team Arguments (Mostly) - My HNG Stage 3 Journey

WI$DOM — Mon, 03 Nov 2025 22:02:10 +0000

The Problem: Team Chats are Where Decisions Go to Die

You know the drill. You're in a team chat. Ideas are flying. Someone makes a great point. Everyone agrees. High-fives all around.

A week later: "Wait, what did we decide about the database again?"

Crickets.

The decision is buried under 300 memes, 50 "lols", and a heated debate about whether pineapple belongs on pizza (it doesn't, fight me). Team discussions are great, but they can be black holes for important decisions.

As part of the HNG Internship, my Stage 3 task was to tackle a problem like this. The challenge? Build an AI agent that integrates with a chat platform, Telex.im, to make sense of the chaos.

So, I built the Decision Note Agent.

What's This Magical Agent You Speak Of?

The Decision Note Agent is a smart assistant that lives in your team chat. Its job is to listen for specific commands, capture decisions, and log them in a structured, searchable way.

No more scrolling endlessly. No more "I thought we agreed on...". Just clear, recorded decisions.

Here's the command list:

/decision propose "Let's use FastAPI for the new service": Propose an idea for the team to vote on.
/decision approve [id]: Approve a proposal.
/decision reject [id]: Reject a proposal.
/decision add "We will use PostgreSQL": Log a decision that's already been made.
/decision list: See all the decisions.
/decision search "database": Find a specific decision.
/decision history: Get the history of all decisions.

Simple, right? The goal was to make it as frictionless as possible.

The Tech Stack: Python, FastAPI, and a Dash of AI

I chose a stack I'm comfortable with but that's also powerful and modern:

Python: Because it's the undisputed king of AI and backend development.
FastAPI: It's a modern, fast (hence the name) web framework for building APIs. Its asynchronous nature is perfect for handling real-time chat interactions.
Gemini AI: To add a little "smart" to the agent, validating decisions and providing summaries.
Telex.im A2A Protocol: This was the trickiest part. It's the "Agent-to-Agent" protocol that allows my agent to talk to the Telex chat platform.

The Journey: Integrating with Telex.im (and Fighting Bugs)

The core of the task was getting my FastAPI application to communicate with Telex.im. This happens through a "well-known" endpoint (/.well-known/agent.json) where my agent advertises its skills, and an A2A endpoint where it receives messages.

Think of it like a job interview. The agent.json file is the resume, listing all the cool things my agent can do (add, propose, list, etc.). The A2A endpoint is the interview itself, where the agent has to actually perform those tasks.

The message format is JSON-RPC, which is a standard for remote procedure calls. It's basically a structured JSON object that says, "Hey agent, a user sent this message. Do something with it."

The Bug Hunt

It wasn't all smooth sailing. My initial build was, to put it mildly, a bit buggy. The logs were filled with "Unknown command" and "Error while streaming". It was like the agent was having a really bad day at the office.

After a lot of debugging, I found the culprits:

The Clueless Agent: My agent.json file was missing half the commands! I was telling Telex my agent could only add and list, so when a user tried to propose or reject, Telex was (rightfully) confused. Fix: I updated the well_known.py file to include all the commands.
The Mismatched Payloads: My main message handler was correctly parsing the command from a complex JSON payload, but the individual command functions were looking for it in the wrong place. It was a classic case of the left hand not knowing what the right hand was doing. Fix: I refactored workflow_handlers.py to pass the correct message text down to every function.

How It All Came Together

After fixing the bugs and updating my README to reflect the actual project structure (whoops), it finally worked. The agent was listening, responding, and logging decisions like a champ.

This HNG task was a rollercoaster. It pushed me to not just write code, but to think about architecture, protocols, and the real-world usability of a tool. It's one thing to build an API; it's another to make it a helpful participant in a team conversation.

If you want to check out the code, you can find the full project on my GitHub.

[https://github.com/CyberwizD/Decision-Note-Agent]

Thanks for reading! Now, go make some (well-documented) decisions.

Pk vs Fk 🔑

WI$DOM — Fri, 29 Aug 2025 10:25:00 +0000

Understanding Primary Keys and Foreign Keys in Relational Databases

When you're building applications, especially with relational databases like PostgreSQL (which is quite familiar), you're not just storing data; you're storing related data — and that's where Primary Keys and Foreign Keys come into play.

They might sound intimidating (not really), but they're fundamental concepts that ensure your data is organized, consistent, and easy to work with. Let's break them down.

Why Do We Need Keys Anyway?

Imagine building an e-commerce platform. You have users, and these users create orders. Without a structured way to connect a specific order to a specific user, your data would be a chaotic mess. You wouldn't know who bought what!

Keys provide that structure.

They are special columns (or groups of columns) that help us:

Uniquely identify each piece of information.
Establish relationships between different pieces of information across various tables.

Primary Key

Think of a Primary Key as the unique identifier for each individual record (row) within a table. No two records in the same table can have the same primary key value. It's like your National Identification Number (NIN) – it identifies only you.

Example

Users Table:

user_id (PK)	username	email	created_at
101	alice	alice@example.com	2023-01-15 10:00:00
102	bob	bob@example.com	2023-01-15 10:05:00
103	charlie	charlie@example.com	2023-01-16 11:30:00

Here, user_id uniquely identifies each user.

If you query for user_id = 102, you'll always get Bob.

Foreign Key

While a primary key identifies a record within its own table, a foreign key links a record in one table to a record in another. It acts as a reference.

A foreign key in Table A points to a primary key in Table B, creating a relationship between them.

Example

Orders Table:

order_id (PK)	user_id (FK)	order_date	total_amount
2001	101	2023-01-15 10:30:00	55.99
2002	102	2023-01-15 11:00:00	120.00
2003	101	2023-01-16 14:00:00	25.50
2004	103	2023-01-17 09:15:00	88.00

Here, user_id in the Orders table is a foreign key referencing user_id in the Users table.

Orders 2001 and 2003 belong to user_id = 101 (Alice).
If we tried to delete Alice (user_id = 101), the database would prevent it (or cascade delete her orders).

In a Nutshell

Primary Key: Uniquely identifies a record in its own table.
Foreign Key: Links a record to a record in another table.

What is Authentication?

WI$DOM — Mon, 28 Jul 2025 20:01:53 +0000

Authentication: Proving You're You

Think about logging into your email account.

When you type in your username and password, you're performing authentication. You're proving to the email service that you are the legitimate owner of that account. If the username and password match what's on file, you're authenticated and granted entry. If they don't, you're denied access. It's simply verifying your identity.

But wait! What's the difference between authentication and authorization? Well, here's a way to simplify it.

Authentication simply means "Who you are" while Authorization simply means "What you can do".

For example, Authentication determines whether someone accessing a website is actually the person who created the account, while Authorization determines what that person is permitted to access once they're identified. Simple, right?

Authentication Mechanisms and Potential Vulnerabilities

Now that we've clarified the basics, let's talk about how authentication systems can be attacked and exploited.

Brute-Force Attack
This is a blunt but often effective method where an attacker performs an automated trial-and-error process, systematically guessing credentials against an authentication system like a login page, SSH, or FTP. The goal is to eventually stumble upon the correct username and password combination.

A common tactic within this attack is Username Enumeration. This occurs when an attacker can validate whether a username is valid or invalid, often by observing different error messages on a login page (e.g., "Username not found" or "Incorrect password"). Once a valid username is identified, the attacker then focuses their brute-force efforts by trying a large wordlist of common or likely passwords against that specific username.

Bypassing Two-Factor Authentication (2FA)
You might think 2FA makes you impenetrable, and it's certainly a strong defense. However, even this crucial security layer isn't always flawless. The implementation of 2FA can sometimes contain weaknesses that allow it to be bypassed entirely.

You know how 2FA typically works, right? You log in with your username and password, and then you're prompted on a separate page to enter a verification code sent to your phone or generated by an app. But what if I told you that some websites don't actually check whether you completed that second verification step?

So you're thinking what I'm thinking? 😏

In some poorly implemented systems, once the initial username and password are submitted, the server might generate a session token before the 2FA code is verified. If an attacker intercepts this token or can manipulate the request to skip the 2FA verification page, they could potentially gain full access to the account without ever entering the second factor. This highlights that even the best security concepts depend heavily on their flawless implementation.

Access Control

WI$DOM — Tue, 22 Jul 2025 13:51:03 +0000

Let's get straight to it.. Accss Control, What does it mean?

So, let's put it this way, you saw this blog, and as you're reading it, you probably saw the typo i wrote Accss, and if you're me, you'd be thinking of editing it. Making it readable, so indirectly you want to edit my blog post 😏.

But here's the critical question: Should you be able to?

This is where Access Control fundamentally comes into play.

Access Control is the gatekeeper that determines who can access what resources, and what actions they're permitted to perform. It's not just about letting people in; it's about defining their privileges once they're inside.

In the context of web applications, access control is dependent on authentication and session management.

Authentication confirms that the user is who they say they are.
Session management identifies which subsequent HTTP requests are being made by that same user.

Have you heard of Vertical Privilege Escalation?
This is when a non-administrative user gains access to an administrative account (a user with a higher level of access), where they can delete user accounts.

Then there's Horizontal Privilege Escalation
This is when a non-administrative user gains access to another non-administrative user's account

Unprotected Functionality
So privilege escalation arises when there's little to no protection to sensitive data. For instance, a user might be able to access administrative functions by browsing to
https://insecure-website.com/admin, https://insecure-website.com/admin or just using a wordlist to brute-force sub-directories that contains administrative functionalities or simply checking the JavaScript on the user interface:

<script> var isAdmin = false; if (isAdmin) { ... var adminPanelTag = document.createElement('a'); adminPanelTag.setAttribute('href', 'https://insecure-website.com/administrator-panel-yb556'); adminPanelTag.innerText = 'Admin panel'; ... } </script>

Parameter-based Access Control Methods
In a web URL https://insecure-website.com/login/home.jsp?admin=true, the parameter admin is set to true. Which means that when a non-administrative user browses to the URL, the user gains admin privileges, due to the parameter admin being set to true. This approach is insecure as the web URL can be modified to gain access.

So with that, you've got an idea on Access Control. Without robust access control, anyone spotting that typo could theoretically change it, or worse, delete the entire blog post.😏

Path Traversal Attack

WI$DOM — Tue, 22 Jul 2025 11:13:10 +0000

So, you've heard... Path Traversal?

Path traversal vulnerabilities is one of the most common server-side vulnerabilities. Well, this is also known as directory traversal.

This vulnerability enables an attacker to access files in a server. These files might include:

Application code and data
Credentials for backend systems
Sensitive files such as users data

In some cases, an attacker can write to a file to modify it. Thereby gaining full access control. So, how do you read these files?

Imagine a shopping application that displays an image, the image loads with the HTML tag:

<img src="/loadImage?filename=218.png">

The LoadImage takes the filename parameter and returns the content of the specified file. The image might be stored in /var/www/images. So what this means is that the stored image path on the server is /var/www/images/218.png.

Now an attacker can read from the file server with https://insecure-website.com/loadImage?filename=../../../etc/passwd which reads /var/www/images/../../../etc/passwd. The ../ means to step up in the directory structure, which means the file actually being read is /etc/passwd.

Here's a simplified story version for you to understand better.

Imagine your website is like a restaurant kitchen. Everything a customer (you, the user) can ask for—menu items, prices, the daily special—is in a specific, public area of the kitchen. That's like your "public files" folder.

Now, imagine there's a back room in that kitchen. This room holds all the secret stuff: the chef's private recipes, the safe with the day's earnings, and employee records. This area is strictly off-limits to customers.

Here's where the problem, called Path Traversal, sneaks in.

A hacker tries to order something from your website. But instead of asking for "menu.pdf," they try a trick:

../../secret_chef_recipes/private_sauce.txt

Think of ../ as telling the website, "Go back one step, then another step."

It's like someone telling the kitchen staff, "Instead of getting me the soup from here, go out of the kitchen, then back through the restaurant door, and then look for the 'secret chef recipes' room!"

If the website isn't careful, it blindly follows these "go back" instructions. Suddenly, it steps outside the public area and hands over the chef's secret sauce recipe – or even worse, the day's earnings!

Path Traversal happens when a website lets a hacker use these ../ tricks to leave the public areas and snoop around for private files they shouldn't see. Sometimes, they can even change these files, just like someone sneaking into the secret room and messing with the recipes!

So, while the concept of Path Traversal might seem simple, its implications are severe. Never trust user input!! 😂

Now that you understand path traversal, next step is to learn who can access what. That's where Access Control comes in. Check out the next blog post. ✌️

Where it all started.

WI$DOM — Fri, 30 May 2025 19:08:20 +0000

My Tech Origin Story

Hey folks, Let me take you to where it all began. Here's a piece of my journey, raw and real.

We all have an origin story in tech, and NO! mine didn’t involve a hoodie, dark terminal screen, and some Matrix-like music playing in the background. I wasn’t “born to code”. If anything, I spent a good chunk of my early dev life asking Google questions like “What's the most interesting career?” and "How do i know what to pursue?”

This post? It’s personal. I wanted to write this now, while everything’s still raw and messy and in-progress. This is my version of leaving breadcrumbs.

So yeah! here’s how I got here, and where I’m headed next.

When I first got curious about tech, I didn’t even know where to begin. I just knew I liked breaking things and figuring out why they broke. That naturally led me to programming. Python was my first real tool: simple, clean, friendly. The kind of language that gently pats you on the back while still letting you shoot yourself in the foot. I wrote a bunch of print statements, tried to build stuff I didn’t fully understand, and kept hitting errors that felt like personal attacks. But every time I fixed something, even something tiny, it felt like magic. Like: “yo, I did that?”

Of course, I went through that phase every dev hits where I tried to learn everything. One week I’m reading up on networking, the next I’m trying to build a scanner app, and somehow I’m knee-deep in a YouTube video about "Top 10 best programming languages to learn" at 1AM (??? 😅). I was moving, but not always forward. And that’s okay. That’s part of the ride.

Somewhere along the way, I discovered cybersecurity.

And it was like someone handed me a new lens to see the entire tech world differently. Suddenly, it wasn’t just about writing code. It was about thinking, figuring out the how and why. And man, that pulled me in deep.

My first few months in cybersecurity were chaotic, lots of scattered learning. I was doing everything: watching Udemy courses, jumping between HackTheBox, TryHackMe, random articles, old forum threads, spent two months reading compTIA+, even skimming through OWASP docs I barely understood at the time. I was trying to find my thing. Red team? Blue team? Maybe purple, maybe chartreuse? 🤣

Then one night, I stumbled across UnixGuy’s video on “Why Most Beginners Fail at Cybersecurity.” That one hit different. It didn’t just teach, it made me reflect. I wasn’t failing, but I was unfocused. I felt a nudge towards application security, and something clicked. Web apps, APIs, misconfigs, vulns. All the messy stuff that lives right at the intersection of code and security. I was home.

Around this time, I was also navigating college, not exactly the ideal multitask setup, but I made it work. I started small: DoS attacks in a lab setup, web hacking, setting up various linux distros just to find what suits best for me (i use kali btw), brute-forcing services (legally, don’t worry), setting up reverse shells, learning how to phish like the bad guys, just so I could learn how to defend like the good ones.

And somewhere in between, I realized something wild:

Small consistent efforts can add up to something big :: Slow progress > No progress

Meanwhile, I kept coding. Python was still my comfort zone, but then Go (Golang) came knocking. And yeah, if Python is like playing with LEGO bricks, Go is like building IKEA furniture with laser precision. It’s clean, fast, and just works. I spent weeks learning the basics and then proceeded to advanced concepts with goroutines, concurrency patterns, channels. It was fun connecting the dots. I built different software ranging from APIs, Backend, CLIs... (Wait, there's more)

Then came the certifications. Along the way, i got the APIsec Certified Practitioner, and that basically flipped a switch in my brain to just how many APIs are out there casually leaking sensitive data like it’s a hobby. It was a whole new level of security stuff, API designs, documentations...

Right now? I’m obsessed with building tools, solving problems, and contributing to anything that mixes code with security. I’ve started focusing on Application security, secure coding, software engineering concepts and principles (Where software meets security). I want to create things that not only work but are hard to break.

And the best part? I know this is still just the beginning.

Looking back, it's clear I'm not just aiming to learn a thousand concepts. I'm really trying to build a thousand projects. Because when you build a thousand projects, you can learn ten thousand concepts.

This post is a bit of a personal checkpoint for me, something to look back on in a few years and see how far I've come.

#LessonLearned

▫️ Your Passion and Curiosity is your Fuel to Greatness
▫️ Don’t rely on every piece of info from social media
▫️ Your Mindset is Everything
▫️ Never Back Down (Consistency is KEY)
▫️ Don't worry about the Future (Flow with the GO)

Big Thanks 🙏
To everyone who's supported me so far; from X (Twitter), LinkedIn, my college course mates, random Discord servers, the cybersecurity community, and all the quiet internet mentors I’ve never met but who changed my mindset forever. Thank you!