DEV Community: Omar Afifi

My Phone Broke, and Gemini Fixed It

Omar Afifi — Wed, 09 Sep 2026 22:26:48 +0000

📱 Picture This: An All-Nighter Turns Into a Morning Nightmare

It is early morning. You’ve just pulled an all-nighter tinkering with an Android project over ADB. The sun is already creeping through the window, tests finally pass, and you unplug the USB cable from your OnePlus to finally go to bed.

You unlock your screen, swipe down to open Settings, and freeze.

Right across your menus is a block of bright-red monospace text:

isOverScrolling: false
X: FlingVX: 0.0, ClickVX: 0.0
Y: FlingVY: 15435.0, ClickVY: 0.0
AbortVX:0.0, AbortVY:15435.0

You stare at it, then touch the screen again. The numbers immediately jump, recalculating in real time with every movement of your thumb. You swipe fast, and FlingVY shoots into the tens of thousands.

Then you notice something even worse: the phone is lagging badly.

When you swipe from the screen edge to go back, the gesture stutters. Pulling out the OnePlus Smart Sidebar hesitates and drops frames. The smooth 120Hz display suddenly feels like a cheap phone struggling to keep up.

🥶 Zero Results: When Google Goes Completely Silent

Your developer reflexes kick in immediately. You jump straight into Developer Options:

Pointer Location? Off.
Show Layout Bounds? Off.
Show Taps? Off.
Strict Mode? Off.

Everything is disabled.

Fine. You hold down the power button and reboot. The phone restarts, you unlock it, open Settings, scroll down—and the red numbers are still right there.

That's when you start to panic. You open your browser and start searching:

"red text on android screen": Generic guides telling you to turn off Developer Options.
"OnePlus red text on screen": Threads asking about the red "1" on the lock screen clock (funny, but not helping).
"OnePlus red text error": Nothing remotely relevant.
"isOverScrolling: false" OnePlus: No results found.
"AbortVX" / "ClickVX": Absolute zero.

Zero results. Not a single thread on XDA Forums, not a mention on Reddit, and nothing on the OnePlus Community.

If you've worked with Android long enough, you know what this silence means: when an issue has zero documentation in AOSP and zero community threads, you're usually looking at a full factory reset.

😴 "That’s Future Me’s Problem"

At that point, the morning sun was already up. I had stayed up all night, I was running on zero sleep, completely exhausted, and my brain felt like an OutOfMemory error. I stared at the red numbers on my screen and made the most mature engineering decision possible:

I decided to go to sleep.

"You know what? This is future me's problem."

I put the phone face-down on the nightstand, closed my eyes, and hoped it would just magically disappear by the time I woke up.

Fast forward to later that afternoon: I woke up, tapped the screen, and nope—the red velocity numbers were still right there, tracking every single swipe while I was still half-asleep.

Now awake and ready to deal with it, I decided it was time to bring in serious backup.

🤖 Handing the Terminal to Gemini

I plugged the USB cable back into my laptop. I opened my Antigravity IDE where I had been pair-programming with Gemini, and typed out of pure frustration:

"Hey, you ran some ADB commands on my phone earlier for some app testing and now there's this weird red text on my screen and the edges are lagging. I plugged it in—fix it."

If this were a standard chatbot, you already know what its first response would be:

"Go to Settings > Developer Options and disable 'Pointer Location', 'Show Layout Bounds', or 'Strict Mode'. If those are already off, try backing up your data and performing a factory reset."

Every standard LLM defaults to that exact script because it assumes you're dealing with standard Android toggles. And when you tell it they're already off, it hits a complete dead end.

Instead, Gemini took the wheel. What happened on my terminal over the next few minutes was impressive: rather than giving boilerplate advice, Gemini started systematically diagnosing the operating system from the inside out.

🎨 Step 1: The Canvas Deduction

Gemini didn't guess. It queried the device's runtime settings via ADB:

adb shell settings get system pointer_location
adb shell settings get system show_touches

Both came back 0. Standard Android touch telemetry was definitively off.

Then Gemini dumped the entire live UI hierarchy of the Settings app:

adb shell uiautomator dump /sdcard/window_dump.xml

It grepped the XML tree for isOverScrolling. The result? Empty.

That silence told Gemini everything:

"This text does not exist as a TextView or a system overlay window. It is being painted directly onto the hardware Canvas buffer during draw passes by an internal UI component."

Because the text appeared during scrolling in OnePlus system menus, Gemini formed an immediate hypothesis: the code belonged to OnePlus/OPPO’s proprietary UI toolkit—COUI (ColorOS UI).

🔬 Step 2: Disassembling the Phone on the Fly

Because these OEM classes are completely proprietary and unreleased, Gemini couldn't look up documentation. It had to read the machine code directly from the phone.

To inspect the COUI framework without needing root access, Gemini pulled a built-in pre-installed app that uses the same UI components:

adb pull /product/app/Calculator2/Calculator2.apk ./calc.apk

Then, right inside my terminal, Gemini wrote and executed Python scripts to parse the raw binary DEX (Dalvik Executable) structures of the APK.

1. Hunting the String Table

Gemini parsed the DEX string pool inside calc.apk and found the exact IDs:

String #2600 = 'AbortVX:'
String #37919 = 'isOverScrolling: '

2. Pinpointing the Method

It mapped those string IDs across every class definition in the binary. In seconds, Gemini had the exact location:

Class: androidx.recyclerview.widget.COUIRecyclerView (OnePlus’s internal extension of the Jetpack RecyclerView)
Method: dispatchDraw(Canvas canvas) at bytecode offset 0x1fbea0

3. Reading the Dalvik Bytecode

Gemini disassembled the opcodes at that offset. The bytecode showed exactly what was going on under the hood:

0x1fbea0: invoke-virtual View->dispatchDraw
0x1fbea6: sget COUIRecyclerView->COUI_DEBUG:Z   // Check static boolean flag
0x1fbeaa: if-eqz -> 0x1fc03c                   // If false, skip entirely!
0x1fbeae: iget COUIRecyclerView->mDebugPaint   // Get Paint object
0x1fbec4: invoke-virtual Paint->setColor       // Set paint color to RED
0x1fbed4: const-string 'isOverScrolling: '     // Format velocity strings
0x1fbf2a: const-string 'X: FlingVX: '
0x1fbf86: const-string 'Y: FlingVY: '
0x1fbfe4: const-string 'AbortVX:'
0x1fc036: invoke-virtual Canvas->drawText      // Draw directly on screen!

There it was: an undocumented, internal scroll-physics debugger built by OEM engineers to measure fling velocities during ROM development.

💥 Step 3: The Domino Effect — Finding Patient Zero

Gemini now knew what was painting the screen, but why had COUI_DEBUG suddenly turned true across my entire phone?

Gemini inspected the class initializer <clinit> of COUIRecyclerView:

0x1fb9bc: const-string 'COUIRecyclerView'
0x1fb9c2: invoke-static COUILog->isLoggable("COUIRecyclerView", Log.DEBUG)
0x1fb9d6: sput COUIRecyclerView->COUI_DEBUG:Z

COUILog.isLoggable() simply calls Android's built-in android.util.Log.isLoggable(tag, level).

In Android, Log.isLoggable() first checks for a tag-specific system property (log.tag.<TAG>). If that doesn't exist, it checks the global fallback property:

🎯 The Culprit: persist.log.tag

Gemini queried the phone:

adb shell getprop persist.log.tag

The terminal printed one character:

Connecting the Dots

Hours earlier, while debugging an audio service over ADB, a command had set persist.log.tag to V (Verbose) to inspect background audio logs.

That one command triggered an unexpected chain reaction:

Why it survived reboots: Properties starting with persist. are saved directly to flash storage (/data/property). A reboot does not wipe them.
Why the red text appeared: Every time any app initialized a scrollable list, COUIRecyclerView checked if debug logging was enabled. Because persist.log.tag was set globally to V, Android replied that everything was in verbose mode. COUI_DEBUG became true, and the red velocity overlay activated.
Why the edges were lagging: With global verbose logging enabled across the entire OS, every single touch event, swipe coordinate, and edge gesture flooded the system log daemon with hundreds of log lines per second. The CPU was overwhelmed with logging I/O, dropping frames and causing noticeable edge touch lag.

⚡ The Cure: Total Relief in Five Seconds

Once Gemini identified the exact root cause, the fix was quick and clean:

1. Resetting the Global Flag

Gemini reset the dangerous persistent global log property to empty:

adb shell setprop persist.log.tag ""

2. Preventing It from Happening Again

To make sure COUIRecyclerView could never wake up its debug drawing again—even if global verbose logging were accidentally enabled in a future project—Gemini injected a permanent tag-level suppression rule:

adb shell setprop persist.log.tag.COUIRecyclerView SUPPRESS

3. Killing the Active Process for Instant Testing

Gemini killed the Settings process to immediately test the fix on the current window:

adb shell am force-stop com.android.settings

Gemini triggered an automated swipe gesture through ADB, captured a live screenshot, and verified that the red text had vanished from Settings.

4. The Final Device Reboot: Flushing In-Memory State

While Settings was fixed immediately, Gemini pointed out a crucial Android runtime mechanic:

In the Dalvik/ART virtual machine, static initializers (<clinit>) run only once when a class is first loaded into a process. That meant any app or system service already running in RAM (like the Launcher, SystemUI, or Contacts) still held COUI_DEBUG = true cached in memory.

To guarantee that every background process, system daemon, and service reloaded cleanly from scratch with the new suppressed properties, we performed a fresh device reboot:

adb reboot

Once the phone rebooted, I picked it up, unlocked it, and scrolled through every corner of the system:

The red text was 100% gone across all apps.
The edges were instantly responsive. Edge gestures, the Smart Sidebar, and the silky 120Hz display were completely restored.
Zero personal data touched, zero system partitions modified.
All temporary extraction scripts were cleanly wiped from both the phone and PC.

🎓 Final Thoughts: An Engineering Student Left Speechless

As a Computer & Systems Engineering student, I usually take AI hype with a grain of salt. I understand how systems work under the hood, and I know how complex and messy OEM Android frameworks get when low-level state gets corrupted.

If I had posted this on a forum or asked a standard chatbot, the advice would have been the same generic response: back up your data and factory reset.

Watching Gemini handle this live in my terminal was genuinely impressive. It didn't guess, and it didn't give generic tips. It followed a solid systems debugging process:

It systematically eliminated UI layers until only hardware Canvas rendering was left.
It pulled compiled OEM packages directly from the phone without needing root access.
It wrote Python scripts on the spot to parse binary DEX string pools and find the right class offsets.
It analyzed the raw Dalvik bytecode and isolated the exact sget instruction controlling the overlay.
It traced an undocumented UI flag back to a persistent Linux system property that had survived reboots.

Watching an AI autonomously reverse-engineer compiled bytecode on a live device—and solve an undocumented framework issue in minutes without touching a single byte of my personal data—was amazing to see.

This isn't just about autocompleting syntax or generating boilerplate code anymore. This is a real glimpse into the future of systems engineering—and as an engineering student, it completely blew me away.

The Ghost in the View Transitions API: A Bizarre Debugging Saga with Google AI 👻

Omar Afifi — Fri, 07 Aug 2026 17:35:35 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

🎨 Project Overview

While working on a major upgrade for my personal portfolio (Check it out here: Live Portfolio Link | GitHub Repo), I built a feature called the Theme Showcase. When a user first loads the homepage, a slick View Transitions API animation sweeps across the screen, temporarily switching the site to one of my custom showcase themes (like "Obsidian" or "Midnight"), before gracefully sweeping back to their chosen default theme. It was a 1.7-second "Wow Effect" designed to show off the site's dynamic color system.

🐛 Bug Fix

Soon after deploying, I noticed a terrifying, chaotic bug. Sometimes, I would open the website and quickly switch to another tab to check an email, or minimize the browser window completely. When I switched back...

Instead of my beautiful default theme, the website was permanently stuck on one of the other showcase themes! The animation had frozen mid-way, leaving the site in an awkward intermediate state. While the website was still fully functional and I could manually fix it by selecting my original theme from the dropdown menu, it was a terrible first impression for a professional portfolio. It was as if a ghost had possessed the CSS.

My first instinct? Smash the refresh button. Refreshing would actually fix the glitch and play the animation perfectly—but only if I stayed patiently on the tab and watched it finish! If I refreshed and immediately switched tabs again, the ghost would return.

💻 Code

Here is the exact code change we made to exorcise the ghost. (You can view the full fix in this GitHub Commit)

The Buggy Code (Before):

const transition = document.startViewTransition(() => {
  html.setAttribute('data-theme', theme);
});

// If the browser aborts the transition here, the Promise rejects and execution halts forever!
transition.ready.then(() => {
  const animation = document.documentElement.animate(/* ... */);
  animation.onfinish = resolve;
});

The Bulletproof Code (After):

let isCancelled = false;

// 1. Gracefully handle tab switching
const handleVisibility = () => {
  if (document.hidden) {
    isCancelled = true;
    html.setAttribute('data-theme', originalTheme); // Instantly restore
    document.removeEventListener('visibilitychange', handleVisibility);
  }
};
document.addEventListener('visibilitychange', handleVisibility);

// 2. Bulletproof the View Transition Promise
return new Promise(resolve => {
  try {
    const transition = document.startViewTransition(() => {
      if (!isCancelled) html.setAttribute('data-theme', theme);
    });

    transition.ready.then(() => {
      if (isCancelled) return resolve();

      const animation = document.documentElement.animate(/* ... */);
      animation.onfinish = resolve;
      animation.oncancel = resolve;

    }).catch(() => {
      // THE MAGIC FIX: If the browser aborts the transition (background tab), resolve immediately!
      resolve();
    });
  } catch (error) {
    // Fallback if startViewTransition throws synchronously
    if (!isCancelled) html.setAttribute('data-theme', theme);
    setTimeout(resolve, duration);
  }
});

🛠️ My Improvements

My technical approach to resolving this was two-fold:

State Management on Visibility Change: I added a visibilitychange event listener. If the user navigates away, we instantly cancel the sequence and forcefully restore the original theme to prevent intermediate states.
Error Handling for the View Transitions API: The core issue was that browsers forcefully abort the startViewTransition when a tab is hidden to save battery. This caused the transition.ready Promise to reject. Because there was no .catch() block, the unhandled rejection caused the entire async sequence to hang permanently. By wrapping the transition in a try/catch and adding a .catch(() => resolve()) handler, we guarantee that the execution flow always continues gracefully, even if the browser interrupts it.

🤖 Best Use of Google AI

I couldn't figure out why this bug was only happening sometimes, and no errors were showing up in the console. So, I turned to my trusty pair programmer: Google AI integrated within the Antigravity IDE.

What's really cool about my workflow is that I chat with my AI agent completely casually in Arabic. It feels incredibly natural, like brainstorming with a senior engineer sitting right next to me. But debugging with AI isn't always a "one-shot" magic trick. It’s an iterative journey.

(Note: I interact with my AI agent natively in Arabic! For this post, I have translated our debugging conversation. I've kept the original Arabic screenshots on hand just in case the judges want to see them!)

Phase 1: The Misdiagnosis

At first, I explained the symptoms loosely to the AI:

Me: "I have another issue. Sometimes the theme changes to dark suddenly and weird things happen. I don't know what it is."

The AI analyzed the code and thought the animation feature itself was the bug (assuming it was just annoying the user). So, it enthusiastically offered a "fix" by completely disabling the showcase animation function!

I had to intervene and correct its assumption:

Me: "Bro, no, you misunderstood! The animation at the beginning is natural and fine. What's NOT natural is leaving the website open, going to another tab, and coming back to find it permanently stuck on a new theme."

Phase 2: The Deep Dive

Once I steered the AI in the right direction, it immediately dug into the mechanics of tab-switching. It realized that modern browsers aggressively pause requestAnimationFrame when a tab goes to the background.

The AI wrote the visibilitychange listener, but then we ran into another issue when I was testing it locally with my dev server.

Me: "Why does it open on a different theme every time I hit save in my editor? I have to manually refresh to get my original theme back."

The AI assumed I was just being impatient with the 1.7-second animation delay during live-reloads:

AI: "When you save, the dev server refreshes the page. The animation starts, switches to the showcase theme, and then returns. You are just manually refreshing before the 1.7 seconds finish, trapping yourself in a loop! Just wait 1.7 seconds."

Phase 3: The "Aha!" Moment

I knew I wasn't just being impatient. The UI was literally getting stuck. I pushed the AI to look deeper:

Me: "Bro, I'm not rushing. I open it, find it on a new theme, and it is completely STUCK on it. This causes problems if the user goes to another tab. Focus well, think carefully, and take your time."

That’s when the AI hit the absolute jackpot.

It didn't just hand me a snippet of code; it provided a masterclass on browser mechanics. It analyzed the View Transitions API behavior and uncovered the true root cause: to save battery and resources, modern browsers aggressively throttle or abort animations when a tab is hidden. This aggressive optimization was causing the transition.ready promise to reject silently, which hung the entire async sequence because it lacked a .catch() block.

I initially asked the AI if we could just "force" the browser to play the animation in the background anyway. Instead of blindly agreeing, the AI pushed back and explained the engineering philosophy behind this: it’s a hard performance constraint built into modern browsers. You can't fight the browser's resource management. Instead, it taught me the "Best Practice": monitor the tab's state (which led to the visibilitychange listener), gracefully catch any forced abortions (the .catch() fix), instantly restore the original UI, and respect the browser's rules.

Thanks to Google AI in the Antigravity IDE, I didn't just fix a bug—I learned exactly why the browser was behaving that way under the hood. It transformed a frustrating debugging session into a profound learning experience about advanced JavaScript APIs and browser rendering mechanics. This is exactly what the future of pair programming looks like!

Reviving Daphq: How I Built an Open-Source, Bare-Metal File Transfer Engine Solo with GitHub Copilot

Omar Afifi — Wed, 27 May 2026 21:12:32 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

Daphq is a robust, open-source, cross-platform file transfer application engineered entirely from scratch to deliver hardware-saturating speeds over local area networks (LAN), Wi-Fi, and Mobile Hotspots.

As a solo developer, I built Daphq to solve a personal frustration: the bloated overhead, privacy concerns, and artificial speed limits of conventional HTTP-based or cloud-reliant file-sharing tools. Daphq bypasses the standard Web/REST layer completely, establishing direct, bare-metal TCP Sockets (Socket & ServerSocket) with SocketOption.tcpNoDelay enabled to eliminate protocol latency and push network hardware to its absolute physical limits.

Built using Flutter (Dart) for seamless cross-platform performance (currently native on Android and Windows), Daphq features a highly decoupled architecture using the BLoC/Cubit pattern, multi-gigabyte memory protection guards, and background network synchronization, and intelligent user guidance.

Demo

The entire project is completely open-source and free to review, fork, or run locally:

🌐 Official Product Website: omar-afifi.com/daphq/
💻 GitHub Repository: github.com/omarafifi-cse/daphq

Screenshots in Action

Android UI Layout	Windows Desktop Experience

Clean, robust mobile layout with active background service tracking.	Fluid, modern, and highly responsive desktop experience.

The Comeback Story

Daphq was born under high pressure, but after shipping the bare bones of version v1.0.0, it was essentially abandoned in my local repository directory. The project had immense raw speed potential, but it was plagued by architectural gaps, clunky user workflows, and high-stress bugs that made it unviable for everyday users.

The GitHub Finish-Up-A-Thon Challenge was the exact catalyst I needed to dust off the codebase and transform it from a fragile command-like utility into a highly polished, resilient consumer application (v2.3.0).

The Deep Evolution: v1.0.0 vs. v2.3.0

Here is exactly how the architecture and UX matured over the course of this challenge:

Discovery, Connectivity & Resilience:
- Before (v1.0.0): Zero automation. Users manually typed cryptic IPv4 addresses, and any connection drop required a full app restart.
- After (v2.3.0): A custom UDP Auto-Discovery Service with an integrated watchdog. Backed by a rewritten, Bulletproof Receiver Engine, the app instantly bounces back if a connection drops or cancels abruptly—never getting stuck on "Connecting...".
User Interface, Fluidity & Storage:
- Before (v1.0.0): Rigid layouts, storage bloat from cached files, and main-thread hangs (UI freezing) when selecting large directories.
- After (v2.3.0): A unified dashboard anchored by an "Orbital Radar" and Non-Blocking Async UI. Sharing 1,000+ files is now buttery smooth with zero lagging. Plus, it features Persistent Folders to permanently remember your download path and Smart Auto-Cleaning to wipe cache bloat automatically.
Smart User Guidance:
- Before (v1.0.0): Users suffered from slow transfers due to ISP router bottlenecks without knowing why.
- After (v2.3.0): Integrated a real-time speed monitor that triggers a Smart Hotspot Guide if speeds drop below 2.0 MB/s, guiding users to utilize 5GHz direct hotspots for up to 10x faster speeds.
Memory Safety & Disk I/O Flow Control:
- Before (v1.0.0): High risk of Out-Of-Memory (OOM) crashes when streaming multi-gigabyte files due to unthrottled asynchronous disk reads.
- After (v2.3.0): Implemented zero-copy byte slicing (Uint8List.sublistView) and Natural Socket Backpressure (await socket.flush()). Daphq now self-throttles to match real-time network speeds, saving physical RAM.
Deep System-Wide Integrations:
- Before (v1.0.0): Isolated sandboxed app.
- After (v2.3.0): Deployed deep OS hooks, including native Android Share Menu entry and background execution. On Android, Instant Wake-up intelligently turns on the screen for incoming requests. On Windows, the Context Menu Shell Extension was completely rebuilt to be unbreakable, eliminating all File Explorer hangs.

My Experience with GitHub Copilot

As a solo developer, you are the software architect, the UI designer, the QA technician, and the DevOps engineer all at once. Time is your greatest bottleneck. Throughout this sprint, GitHub Copilot didn’t just autocomplete lines of boilerplate—it acted as an incredibly knowledgeable senior engineering peer, unlocking complex architectural problems.

Here are three distinct breakthroughs where GitHub Copilot completely changed the trajectory of the project:

1. Solving the Math of the Orbital Radar UI

I wanted the home dashboard to feel alive with an evenly distributed, deterministic "Orbital Radar" circle showing available peer devices. Distributing dynamic widgets symmetrically on a circular plane without them overlapping can quickly become a headache.

Copilot's Intervention: By providing Copilot with my layout boundaries and device state arrays, it instantly mapped out the exact trigonometric distribution math using cos and sin over a mapped index. Furthermore, it proactively recommended assigning unique ValueKeys to the dynamically generated widgets, preventing unnecessary re-paints and maximizing rendering performance on low-end hardware.

2. Eliminating the Windows FFI Mutex Deadlock

A critical, highly frustrating platform bug on Windows caused Daphq to accidentally trigger background execution loops whenever a user performed completely unrelated right-click shell actions elsewhere in the OS. Worse, exiting the app caused a stubborn Dart VM deadlock.

Copilot's Intervention: I explained the process conflict to Copilot. It guided me through structuring a clean, platform-specific local session mutex check. When it came to bypassing the Dart VM shutdown hang, Copilot instantly generated the safe native Windows FFI code block to execute a clean ExitProcess command, killing the deadlocks instantly and safely.

3. Engineering Flow-Safe Dynamic Streaming Buffer

To stop aggressive disk-read bursts from triggering Out-Of-Memory exceptions, I needed a way to throttle file streams smoothly based on network capacity.

Copilot's Intervention: Copilot analyzed my asynchronous data-sync loop and suggested transitioning away from arbitrary chunk delay timers. It helped refactor the code to explicitly await socket.flush() based on monitored bytesBuffered thresholds. The result was an automated backpressure loop that scales throughput up or down safely based on real-time network conditions.

// Standard path for larger files: stream in chunks
final reader = fileToRead.openRead();
try {
  await for (var chunk in reader) {
    if (_isCancelled) throw "Transfer Cancelled";
    try {
      socket.add(chunk);
      bytesBuffered += chunk.length;

      if (bytesBuffered >= AppConstants.socketFlushThresholdBytes) {
        // Awaited flush: provides backpressure so the disk read loop
        // runs at network speed, not disk speed. Without this, a fast
        // UFS device would read the entire file in <500ms before any
        // onUpdate fires, causing the snapshot/stutter UI bug.
        await socket.flush();
        bytesBuffered = 0;
      }
    } catch (e) {
      if (_isCancelled) throw "Transfer Cancelled";
      if (e is SocketException || e.toString().contains("reset by peer")) {
        throw "Receiver disconnected during transfer.";
      }
      rethrow;
    }

    // ... UI update logic 
  }
}

The Verdict

Building Daphq independently meant encountering dozens of architectural edge cases. Having GitHub Copilot available to instantly generate platform-specific guards, analyze multi-threaded socket behavior, and handle tedious Win32 registry bindings allowed me to focus on what mattered most: delivering a breathtakingly fast file transfer engine.

Daphq went from an unpolished repository artifact to a production-grade open-source engine capable of hitting 80-90 MB/s (~93% bandwidth saturation) over a standard local Wi-Fi 5 connection. I couldn't be prouder of how this challenge ended.