{
  "schemaVersion": 1,
  "profile": {
    "name": "The Drunken Coder",
    "headline": "Systems, maps, mesh networking, and robotics",
    "bio": "I build systems where maps, backend services, and radio networks work together. My projects include mesh provisioning, computer-vision evaluation, drone and rover integration, and tools that connect these systems. I focus on clear interfaces and workflows I can run locally, measure, and replay.",
    "links": [
      {
        "label": "GitHub",
        "url": "https://github.com/the-Drunken-coder"
      }
    ],
    "avatar": {
      "kind": "image",
      "src": "assets/profile/e4313ec9c2a1b4cb-github-avatar.jpg",
      "alt": "The Drunken Coder GitHub avatar showing an off-road vehicle."
    }
  },
  "featuredProjectIds": [
    "atlas-systems",
    "cvbench",
    "easymanet"
  ],
  "projects": [
    {
      "id": "atlas-core",
      "parentProjectId": "atlas-systems",
      "title": "Atlas Core",
      "summary": "A Go backend, shared contracts, and TypeScript SDK for Atlas, connecting asset state, assigned work, collected files, and independent Plugins.",
      "role": "Solo designer and developer",
      "status": "in-progress",
      "updatedAt": "2026-10-08",
      "skills": [
        "Go",
        "TypeScript",
        "Python",
        "SQLite",
        "OpenAPI",
        "oapi-codegen",
        "sqlc",
        "Ajv",
        "Integration testing",
        "Process supervision"
      ],
      "links": [
        {
          "label": "Source",
          "url": "https://github.com/atlas-field-systems/atlas-core"
        }
      ],
      "media": [],
      "story": "## Problem\n\nI designed Core, Protocol, and the SDK around one local server that owns Atlas state and accepted work. Applications share contracts and access data without depending on private storage. [Core overview](https://github.com/atlas-field-systems/atlas-core/blob/81651f8282453df0144789a91d660a9acb23f105/README.md).\n\n## State and work\n\nCore organizes its API around three responsibilities:\n\n* Entities owns Asset identity and state, Tracks and observations, Geofeatures, relationships, and movement history.\n* Tasks validates Commands, assigns work, and records delivery, progress, cancellation, and outcomes. Asset software owns execution and onboard scheduling; Core distinguishes requested queue order from the order the Asset adopts.\n* Objects owns collected files, metadata, associations, and provenance. Immutable file content becomes visible only after complete publication.\n\nPlugins, identity and access, synchronization, and system operations support these responsibilities inside one server. [Responsibility map](https://github.com/atlas-field-systems/atlas-core/blob/81651f8282453df0144789a91d660a9acb23f105/docs/architecture/system-outline.md#atlas-core-responsibility-map).\n\n## Contracts and synchronization\n\nProtocol defines external contracts and the Command Catalog. OpenAPI generates Go and TypeScript bindings. The SDK gives interfaces, Plugins, IP-connected Assets, and gateways one read/query/subscription API, using direct HTTP reads or a synchronized local picture. Writes go to Core. Core sends consistent snapshots and ordered committed updates; the SDK validates them, recovers connections, and applies local updates atomically. [SDK responsibilities](https://github.com/atlas-field-systems/atlas-core/blob/81651f8282453df0144789a91d660a9acb23f105/docs/topics/sdk.md) and [delivery design](https://github.com/atlas-field-systems/atlas-core/blob/81651f8282453df0144789a91d660a9acb23f105/docs/adr/0020-limit-general-sdk-to-http-and-full-sync.md).\n\nAuthenticated gateways author reports only for their bound Assets. Each Asset retains its identity and Task records. [Gateway authority](https://github.com/atlas-field-systems/atlas-core/blob/81651f8282453df0144789a91d660a9acb23f105/docs/adr/0028-trust-gateways-to-author-bound-asset-reports.md).\n\n## Plugin operations\n\nPlugins own processing algorithms and results, use the SDK, and can publish Entities or Objects and initiate existing Asset Commands. Invocations are Operations, separate from Asset Tasks. Accepted Operations retain progress and outcomes, outlive caller connections, and support cancellation. Core records interrupted execution as uncertain without automatic retry. Discovery and Operations use explicit API reads outside synchronized state. [Plugin lifecycle](https://github.com/atlas-field-systems/atlas-core/blob/81651f8282453df0144789a91d660a9acb23f105/docs/topics/plugins.md).\n\n## Deployment and lifecycle\n\nOne Linux installation runs a Go Core container and sibling Plugin containers under Docker Compose. Core stores state in SQLite and Object content in private local files. A shared host-side management module powers the CLI and TUI for installation, configuration, lifecycle, and Plugin management. [Stack decision](https://github.com/atlas-field-systems/atlas-core/blob/81651f8282453df0144789a91d660a9acb23f105/docs/adr/0016-use-go-sqlite-and-openapi-tooling.md) and [deployment design](https://github.com/atlas-field-systems/atlas-core/blob/81651f8282453df0144789a91d660a9acb23f105/docs/adr/0017-deploy-core-and-plugins-as-docker-containers.md).\n\nMounted data survives container replacement and Start, Stop, and Restart. Reset clears operational data while retaining setup; Hard Reset clears setup too. [Retention rules](https://github.com/atlas-field-systems/atlas-core/blob/81651f8282453df0144789a91d660a9acb23f105/docs/adr/0015-separate-start-stop-restart-and-reset.md).\n"
    },
    {
      "id": "atlas-systems",
      "title": "Atlas Systems",
      "summary": "A command-and-control system for sensors and robotic assets, with off-grid communications and flexible deployment.",
      "role": "Solo designer and developer",
      "status": "in-progress",
      "updatedAt": "2026-10-08",
      "skills": [
        "System design",
        "API contracts",
        "Offline system design",
        "Repository organization"
      ],
      "links": [
        {
          "label": "GitHub organization",
          "url": "https://github.com/atlas-field-systems"
        }
      ],
      "media": [],
      "story": "## Problem\n\nI designed Atlas for flexible control of sensors and robotic assets across a large area, including over low-bandwidth and off-grid links. Difficulty integrating inexpensive custom drones into ATAK's UAS tooling motivated me to build a system around my own devices and workflows.\n\n## System design\n\nThe architecture connects communications, command and control, mesh networking, task orchestration, and data display around a local Core server. Core owns the shared operational state. The Command Interface owns maps, navigation, and resource views; closing it leaves accepted work running. Protocol defines shared contracts, and the SDK connects applications to Core. [Operating model](https://github.com/atlas-field-systems/atlas-core/blob/81651f8282453df0144789a91d660a9acb23f105/docs/architecture/operating-model.md) and [system outline](https://github.com/atlas-field-systems/atlas-core/blob/81651f8282453df0144789a91d660a9acb23f105/docs/architecture/system-outline.md).\n\nAsset software controls physical execution. Gateways translate between Core's IP connection and constrained radio links, while independently managed Plugins handle processing and external-source integrations. The Command Interface, Core, and gateways can share one laptop or run across separate systems. Installed local capabilities work without internet when clients can reach Core. [Gateway placement](https://github.com/atlas-field-systems/atlas-core/blob/81651f8282453df0144789a91d660a9acb23f105/docs/topics/sdk.md#bandwidth-and-gateways), [Plugin model](https://github.com/atlas-field-systems/atlas-core/blob/81651f8282453df0144789a91d660a9acb23f105/docs/topics/plugins.md#what-a-plugin-is), and [offline operation](https://github.com/atlas-field-systems/atlas-core/blob/81651f8282453df0144789a91d660a9acb23f105/docs/adr/0010-operate-without-internet-access.md).\n\n## Command flow\n\nAn operator submits a scan Task through the SDK. Core validates and records it, and the Asset receives instructions directly or through a gateway. The Asset executes the work and reports its outcome, reconciling progress and cancellations when a radio connection returns. Collected files become readable Objects after complete publication. A separate Plugin Operation processes a ready Object and can publish detections into the shared picture, which the SDK delivers to the interface. Task completion records physical execution independently of file availability. [Scan workflow](https://github.com/atlas-field-systems/atlas-core/blob/81651f8282453df0144789a91d660a9acb23f105/docs/architecture/operating-model.md#scan-data-and-processing) and [completion boundary](https://github.com/atlas-field-systems/atlas-core/blob/81651f8282453df0144789a91d660a9acb23f105/docs/adr/0026-record-asset-completion-independently-of-result-availability.md).\n\n## Earlier platform demonstration\n\nOn the earlier Atlas platform, I demonstrated sending a command from the interface through Core to an asset and receiving a response over a LoRa mesh. I have used my independently developed Atlas software in group robotics projects.\n"
    },
    {
      "id": "doug",
      "title": "Doug",
      "summary": "An ArduPilot quadcopter for autonomy experiments and Atlas integration, with local flight tests and Python flight-log analysis.",
      "role": "Solo creator",
      "status": "in-progress",
      "updatedAt": "2026-09-27",
      "skills": [
        "ArduPilot",
        "Pixhawk",
        "Python",
        "pymavlink",
        "Hardware integration",
        "Telemetry analysis",
        "Flight-log analysis"
      ],
      "links": [],
      "media": [],
      "story": "## Problem\n\nI assembled Doug as a hardware baseline for learning flight-controller integration, exploring autonomy, and connecting Atlas to a physical platform. I chose an inexpensive, off-the-shelf F450 quadcopter kit so I could work within a known design and keep integration straightforward.\n\n## How it works\n\nI handled the assembly and integration of the kit, Pixhawk flight controller, GPS, and ArduPilot software. The work combines radio setup, vehicle configuration, ground checks, and local flight tests. Python tools turn DataFlash logs into comparable JSON and Markdown reports with mode changes, selected health measurements, and takeoff-relative tracks. The repository has summaries for 14 historical logs; raw logs and geographic positions remain separate.\n\n## Larry variant\n\nI built Larry from the same basic kit and system for my junior-year WPI Major Qualifying Project. It provides a smaller, more manageable alternative to the DJI Matrice 600, with an easier companion-computer mount and longer landing gear to carry an antenna underneath.\n\n## Current state\n\nThe project record documents local flights, including Loiter and short-range return-to-launch tests. Log analysis helps review what the vehicle reported. Control-direction and calibration checks remain open, so the recorded tests describe individual observations rather than general autonomous reliability.\n"
    },
    {
      "id": "drone-assisted-signal-source-localization",
      "title": "Drone-Assisted Signal Source Localization",
      "summary": "A WPI team research project where I integrated robotic platforms, Atlas command and control, and a LoRa mesh datalink.",
      "role": "Team project co-advisor, platform integration and datalink",
      "status": "in-progress",
      "updatedAt": "2026-09-27",
      "skills": [
        "Hardware integration",
        "Companion computers",
        "LoRa",
        "IP networking",
        "Command interfaces",
        "Systems testing"
      ],
      "links": [
        {
          "label": "WPI MQP report",
          "url": "https://digital.wpi.edu/show/tb09jb092"
        },
        {
          "label": "WPI poster program",
          "url": "https://www.wpi.edu/sites/default/files/2026-04/ECE-URPS-2026_0.pdf"
        }
      ],
      "media": [
        {
          "kind": "image",
          "src": "assets/projects/drone-assisted-signal-source-localization/dddac96a1dc4c5b8-team-working-on-drone.jpeg",
          "alt": "The WPI project team working around a DJI Matrice 600 Pro outdoors.",
          "caption": "Samin Khandaker, Gift Kuepouo, and Lane Araujo working on the drone. Photo by Beth Irwin."
        }
      ],
      "story": "## Problem\n\nThe WPI team explored detecting phone-related radio signals and supporting survivor-to-rescuer communication when normal infrastructure is unavailable. I joined the existing team during 2025-2026 and focused on connecting software to the physical platforms. The [published MQP report](https://digital.wpi.edu/show/tb09jb092) credits me as a co-advisor.\n\n## My contribution\n\nI wrote Atlas independently and handled companion-computer and platform integration, the command interface, and the LoRa mesh datalink. On the platform, I demonstrated a command-and-response round trip from the interface through the Atlas core to an asset and back. Atlas provided communications, command and control, mesh networking, task orchestration, and platform data display. This was the field Atlas implementation used in that year's project.\n\nI also built the Larry variant of Doug for my junior-year MQP, with a simpler companion-computer mount and longer landing gear for an antenna underneath. I built and adapted Frank as the ground antenna platform. A teammate wrote the SDR signal-reading software.\n\n## How it works\n\nThe team used a DJI Matrice 600 Pro, a USRP E312, a Raspberry Pi 5, and a directional horn antenna. Samin Khandaker worked on RF capture and analysis, including comparisons between baseline and later recordings. Beth Irwin and Gift Kuepouo developed RescueLink for local survivor/rescuer communication. Frank provided an alternative ground carrier for the antenna when the drone was unavailable.\n\n## Current state\n\nThe [report dated 29 April 2026](https://digital.wpi.edu/downloads/wd3761474) documents the team's 2025-2026 work. The project includes hardware integration, flight tests, the demonstrated Atlas command path, and RF capture and change detection. A landing crash led to using Frank as an interim antenna carrier. The RF example detects a phone hotspot; measured source-localisation accuracy and an end-to-end rescue deployment are not established.\n"
    },
    {
      "id": "frank",
      "title": "Frank",
      "summary": "A tracked ArduPilot rover for Atlas and autonomy experiments, adapted as an antenna carrier for a WPI signal localisation project.",
      "role": "Solo platform builder; collaborative RF work",
      "status": "in-progress",
      "updatedAt": "2026-09-27",
      "skills": [
        "ArduPilot",
        "Pixhawk",
        "Ground robotics",
        "Hardware integration",
        "Systems testing"
      ],
      "links": [],
      "media": [
        {
          "kind": "image",
          "src": "assets/projects/frank/08b3b7075c7978db-antenna-carrier.jpeg",
          "alt": "Frank tracked rover carrying a directional horn antenna on a wooden upright in a workshop.",
          "caption": "Frank carrying the directional antenna during the WPI project. Signal capture system credited to Samin Khandaker and Lane Araujo."
        }
      ],
      "story": "## Problem\n\nI built Frank as a ground platform for autonomy and Atlas command-and-communications experiments, then adapted it to carry an antenna for the WPI signal localisation project.\n\n## How it works\n\nBuilt in spring 2026, Frank combines a tracked chassis with a Pixhawk controller running ArduPilot. I handled the hardware, platform integration, and Atlas integration for both the original rover and the antenna-carrier adaptation. Atlas ran on the rover for command, control, and communications work.\n\nFor the WPI project, I mounted the directional antenna on a wooden support. A teammate wrote the SDR software that read the signals. Samin Khandaker and I are credited for the collaborative signal capture system.\n\n## Current state\n\nFrank became an interim antenna carrier after the project's final drone flight test ended in a landing crash. The photo shows the adapted platform used in the project.\n"
    },
    {
      "id": "cvbench",
      "title": "CVBench",
      "summary": "A computer-vision evaluation ecosystem combining whole-system tracking benchmarks, provenance-aware datasets, and local video annotation.",
      "role": "Solo designer and developer",
      "status": "in-progress",
      "updatedAt": "2026-09-02",
      "skills": [
        "Python",
        "JavaScript",
        "NumPy",
        "OpenCV",
        "Docker",
        "Cloudflare Workers",
        "D1",
        "R2",
        "Computer vision",
        "Dataset provenance"
      ],
      "links": [
        {
          "label": "Benchmark source",
          "url": "https://github.com/the-Drunken-coder/cvbench-benchmark"
        },
        {
          "label": "Dataset source",
          "url": "https://github.com/the-Drunken-coder/cvbench-dataset"
        },
        {
          "label": "Studio source",
          "url": "https://github.com/the-Drunken-coder/cvbench-studio"
        }
      ],
      "media": [
        {
          "kind": "image",
          "src": "assets/projects/cvbench/6231cff48adfbb1a-dataset-catalog.png",
          "alt": "CVBench dataset catalog distinguishing training drafts from certified evaluation data.",
          "caption": "Dataset catalog showing review and evaluation states, from the project repository."
        },
        {
          "kind": "image",
          "src": "assets/projects/cvbench/893e44ccdad65d75-scenario-viewer.png",
          "alt": "CVBench scenario viewer inspecting a synthetic target, frame timing, annotations, and validation evidence.",
          "caption": "A deterministic synthetic tracking sequence in the CVBench scenario viewer."
        }
      ],
      "story": "## Problem\n\nI built CVBench to experiment with computer vision for security cameras and drones. I wanted to evaluate initial target identification and what happens when tracking loses a target through occlusion or needs to continue across sensors. That led to a repeatable workflow for comparing tracking behavior on synthetic sequences and real video.\n\n## How it works\n\nThe Python benchmark runner sends timestamped frames to a tracking system, records returned events, and produces separate accuracy, latency, robustness, and resource results. Source timing remains distinct from replay speed. Submitted model containers run with network access disabled and resource limits, while the host measures their resource use. [Runner](https://github.com/the-Drunken-coder/cvbench-benchmark/blob/406ea2e73f92999b48f7ea57f73e9d33a8ff353f/src/cvbench/runner.py) and [execution boundary](https://github.com/the-Drunken-coder/cvbench-benchmark/blob/406ea2e73f92999b48f7ea57f73e9d33a8ff353f/src/cvbench/runtime.py).\n\nThe dataset repository keeps source provenance, annotations, and reviews together. Review approvals bind to artifact hashes, and certified benchmark truth is kept separate from training drafts. [Dataset validation](https://github.com/the-Drunken-coder/cvbench-dataset/blob/74b8ddd0501586adebbf5a2be605b4483323fdee/src/cvbench_dataset/validator.py).\n\nCVBench Studio supplies a local browser interface for video import, frame annotations, tracks, and draft exports. Model proposals remain separate from reviewed annotations until a person imports and reviews them. [Studio workflow](https://github.com/the-Drunken-coder/cvbench-studio/blob/52a26953f7fb9ec2b12a7e5ed4c689453fd03ffb/README.md).\n\n## Current state\n\nI saved an evaluation of a basic classical motion tracker on three MEVA video clips. The tracker uses frame differencing, simple shape-based classification, and constant-velocity association as a transparent lower-bound baseline. The recorded run exposes missed targets and weak track association, giving me concrete failure cases to inspect on real footage. [Saved evaluation](https://github.com/the-Drunken-coder/cvbench-benchmark/blob/406ea2e73f92999b48f7ea57f73e9d33a8ff353f/scenario-catalog/evidence/real-video-v2.json) and [motion baseline](https://github.com/the-Drunken-coder/cvbench-benchmark/blob/406ea2e73f92999b48f7ea57f73e9d33a8ff353f/examples/models/real-video-motion-baseline/README.md).\n\nThe benchmark, datasets, and Studio remain a personal experiment with shared contracts. The screenshots show the dataset catalog and a synthetic scenario alongside this real-video evaluation workflow.\n"
    },
    {
      "id": "easymanet",
      "title": "EasyMANET",
      "summary": "A tool that flashes and configures OpenMANET nodes from one fleet description, applying settings automatically on first boot.",
      "role": "Solo designer and developer",
      "status": "in-progress",
      "updatedAt": "2026-08-15",
      "skills": [
        "Python",
        "Electron",
        "JavaScript",
        "OpenWrt",
        "OpenMANET",
        "Docker",
        "YAML",
        "Shell",
        "Release automation",
        "Hardware provisioning"
      ],
      "links": [
        {
          "label": "Source",
          "url": "https://github.com/the-Drunken-coder/easymanet"
        },
        {
          "label": "Image pipeline",
          "url": "https://github.com/the-Drunken-coder/easymanet-images"
        },
        {
          "label": "CLI",
          "url": "https://github.com/the-Drunken-coder/easymanet-cli"
        },
        {
          "label": "Desktop console",
          "url": "https://github.com/the-Drunken-coder/easymanet-desktop"
        }
      ],
      "media": [
        {
          "kind": "document",
          "src": "assets/projects/easymanet/8579f202ecd53bee-sample-fleet.yml",
          "label": "Sample three-node fleet configuration"
        }
      ],
      "story": "## Problem\n\nEasyMANET grew out of my Atlas and robotics work, where I wanted to extend IP communications through an easier-to-configure mesh. OpenMANET's Raspberry Pi setup involves flashing an image, connecting over Ethernet, and using a browser wizard on each node. Shared mesh settings then need to agree across the fleet. [OpenMANET setup](https://openmanet.github.io/docs/initial-setup/raspberry-pi).\n\n## How it works\n\nI built EasyMANET as a separate provisioning tool that flashes and configures OpenMANET. One validated fleet configuration replaces repeated manual node setup. The shared Python core resolves node overrides, plans disk operations, flashes the image, and stages a node-specific boot payload. OpenWrt first-boot scripts apply those settings automatically. CLI and Electron interfaces use the same workflow. [Architecture](https://github.com/the-Drunken-coder/easymanet/blob/5983688c7eddaa1c64c38a71b27c5c8d72fdd333/docs/architecture.md) and [shared flash workflow](https://github.com/the-Drunken-coder/easymanet/blob/5983688c7eddaa1c64c38a71b27c5c8d72fdd333/packages/core/src/easymanet/flash.py).\n\nDisk selection is explicit, dry runs expose the plan, and checks reject unsafe targets before writing. The image pipeline, CLI, and desktop console are published from the shared authoring repository. [Flashing behavior](https://github.com/the-Drunken-coder/easymanet/blob/5983688c7eddaa1c64c38a71b27c5c8d72fdd333/docs/flashing.md) and [product ownership](https://github.com/the-Drunken-coder/easymanet/blob/5983688c7eddaa1c64c38a71b27c5c8d72fdd333/docs/public-repos.md).\n\n## Current state\n\nThe implemented local workflow targets Raspberry Pi 4 with MM6108 SPI running OpenMANET. It takes a fleet description through validation, flashing, and first-boot configuration. The downloadable fleet file is an unchanged copy of the upstream EasyMANET example with placeholder settings.\n\n[Download the sample fleet](assets/projects/easymanet/8579f202ecd53bee-sample-fleet.yml).\n"
    },
    {
      "id": "sidc-kit",
      "title": "SIDC Kit",
      "summary": "A TypeScript library and CLI for searching, explaining, building, and rendering Symbol Identification Codes with explicit semantic coverage.",
      "role": "Solo designer and developer",
      "status": "in-progress",
      "updatedAt": "2026-06-27",
      "skills": [
        "TypeScript",
        "Node.js",
        "milsymbol",
        "SVG",
        "Library design",
        "Browser bundling",
        "npm",
        "Release automation"
      ],
      "links": [
        {
          "label": "Source",
          "url": "https://github.com/the-Drunken-coder/sidc-kit"
        },
        {
          "label": "Release v0.3.2",
          "url": "https://github.com/the-Drunken-coder/sidc-kit/releases/tag/v0.3.2"
        }
      ],
      "media": [],
      "story": "## Problem\n\nI built SIDC Kit for asset mapping in Atlas. Symbol Identification Codes are compact but difficult to author and interpret directly, so I wanted a reusable interface that made integration easier and kept symbol-handling code out of the rest of the application.\n\n## How it works\n\nThe library uses the upstream milsymbol renderer and adds a curated semantic catalog. It searches plain-language terms, explains known code fields, builds supported combinations, and renders SVG. Its CLI uses the same API and data model. Typed errors distinguish malformed input, unsupported combinations, and ambiguous requests. [API and coverage](https://github.com/the-Drunken-coder/sidc-kit/blob/ea04c9b96b0d5ba66e5f46bd87b6d23f86260c6c/README.md) and [public exports](https://github.com/the-Drunken-coder/sidc-kit/blob/ea04c9b96b0d5ba66e5f46bd87b6d23f86260c6c/src/index.ts).\n\nReverse lookup compares clean SVG renderings against the curated set. Browser checks bundle the public package entrypoint and exercise search and rendering, keeping the runtime independent of Node built-ins. [Browser consumption check](https://github.com/the-Drunken-coder/sidc-kit/blob/ea04c9b96b0d5ba66e5f46bd87b6d23f86260c6c/scripts/browser-smoke.mjs).\n\n## Current state\n\nA public [v0.3.2 release](https://github.com/the-Drunken-coder/sidc-kit/releases/tag/v0.3.2) is available. I have reused SIDC Kit in my own projects, and friends have used it in an order-of-battle editor and a global unit tracker. Rendering comes from milsymbol; the semantic search, build, and reverse-lookup catalog has explicitly defined coverage.\n"
    },
    {
      "id": "meshtastic-wifi-bridge",
      "title": "Meshtastic WiFi Bridge",
      "summary": "An experimental bridge for web and API requests over Meshtastic radios, developed for Atlas testing and off-grid communication.",
      "role": "Solo designer and developer",
      "status": "in-progress",
      "updatedAt": "2026-02-11",
      "skills": [
        "Python",
        "Meshtastic",
        "Flask",
        "MessagePack",
        "Zstandard",
        "Transport protocols",
        "Serialization",
        "Hardware test tooling"
      ],
      "links": [
        {
          "label": "Source",
          "url": "https://github.com/the-Drunken-coder/Meshtastic-WIFI-bridge"
        }
      ],
      "media": [],
      "story": "## Problem\n\nI built this bridge partly for Atlas beta testing, so applications could make familiar web and API requests over radio without each implementing its own application protocol. I was also interested in access to small services in disaster areas where ordinary connectivity might be unavailable.\n\n## How it works\n\nThe bridge handles the low-bandwidth transport behind those requests. Its Python transport uses compressed MessagePack envelopes, chunk reassembly, acknowledgment strategies, deduplication, and an optional outgoing spool. A Flask interface supplies the browser side, while a gateway performs HTTP requests on behalf of messages received over the mesh. [System design](https://github.com/the-Drunken-coder/Meshtastic-WIFI-bridge/blob/6d45c8cd11e1cfc4c93e007bfd7c56889005a141/docs/SYSTEMS_DESIGN.md) and [gateway implementation](https://github.com/the-Drunken-coder/Meshtastic-WIFI-bridge/blob/6d45c8cd11e1cfc4c93e007bfd7c56889005a141/src/gateway.py).\n\n## Current state\n\nIn my radio tests, I browsed Wikipedia slowly, received responses from an LLM API, and fetched weather API data. These demonstrations showed that simple pages and small request-and-response exchanges were usable over the link. The project remains an experimental bridge for constrained connections.\n"
    },
    {
      "id": "autobex-2",
      "title": "AutoBex 2",
      "summary": "A map application for exploring abandoned and disused places recorded in OpenStreetMap, using city, radius, and polygon searches.",
      "role": "Solo designer and developer",
      "status": "in-progress",
      "updatedAt": "2026-01-01",
      "skills": [
        "JavaScript",
        "Leaflet",
        "OpenStreetMap",
        "Overpass",
        "Cloudflare Pages",
        "Geospatial interfaces"
      ],
      "links": [
        {
          "label": "Source",
          "url": "https://github.com/the-Drunken-coder/Autobex-2"
        }
      ],
      "media": [],
      "story": "## Problem\n\nI built AutoBex to find nearby abandoned places and historical sites to explore, catalogue, and photograph. AutoBex 2 is the version I rebuilt in my second year of college, after starting the first version in my first year.\n\n## How it works\n\nSearches can start with a city, a point and radius, or a drawn area. The JavaScript/Leaflet interface shows the search area, clusters results, and supports sorting and nearby-place grouping. Cloudflare Pages Functions translate searches into geocoding and Overpass queries, filter selected OpenStreetMap tags, and deduplicate results. [Map interface](https://github.com/the-Drunken-coder/Autobex-2/blob/6660d9f2b7974ee00566c863605417a6b30c16e5/public/app.js) and [search endpoint](https://github.com/the-Drunken-coder/Autobex-2/blob/6660d9f2b7974ee00566c863605417a6b30c16e5/functions/api/search.js).\n\n## Current state\n\nThe app turns community-maintained OpenStreetMap records into a map of candidate places to investigate. It gives me a way to narrow a broad area into nearby exploration leads; the results depend on what contributors have mapped and tagged.\n"
    }
  ]
}