DEV Community

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

Posted on

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

#devchallenge #githubchallenge #flutter

GitHub “Finish-Up-A-Thon” Challenge Submission

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:

Screenshots in Action

Android UI Layout Windows Desktop Experience
Android Interface Windows Interface
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.2.0).

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

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

  • Discovery & Connectivity:
    • Before (v1.0.0): Zero automation. Users had to manually look up and type cryptic local IPv4 addresses.
    • After (v2.2.0): A custom UDP Auto-Discovery Service that actively scans subnets and features an integrated watchdog mechanism to instantly heal connections during IP changes.
  • User Interface & Fluidity:
    • Before (v1.0.0): Rigid layouts and main-thread hangs (UI freezing) when selecting massive directories.
    • After (v2.2.0): A unified dashboard anchored by a premium "Orbital Radar", coupled with Non-Blocking Asynchronous UI. Directory resolution is now fully offloaded from the main thread, accompanied by a persistent Transfer History system.
  • Smart User Guidance:
    • Before (v1.0.0): Users often suffered from slow transfers due to ISP router bottlenecks without knowing why.
    • After (v2.2.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.2.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.
  • System-Wide Integrations:
    • Before (v1.0.0): Isolated sandboxed app.
    • After (v2.2.0): Deployed deep OS hooks, including native Android Share Menu entry, background execution via Android Foreground Services, and a Windows Context Menu Shell Extension.

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 
  }
}
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (0)