I had Ruby running on a 2009 iPhone. Then I needed something to run.

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

I had Ruby 4.0.7 running on a 2009 iPhone 3GS. I just didn't know what to run on it.

Then this challenge gave me an idea: turn the phone into a home network dashboard connected to a local AI model.

I built it for my best friend: myself. It do not solves any problems but it let me learned some new concepts.

The Ruby port was already part of a larger side project. The dashboard is the new project I built for this challenge. I wanted something to run on the phone and something to write about here.

The phone shows devices on my home network. I can type commands or ask questions about the latest device scan. A model on my PC answers the questions. The phone runs the Ruby dashboard; the PC runs the model.

iPhone 3GS (Ruby daemon, Safari)
      └── HTTP LAN ──> Mac (Ruby agent: scan / ping / wake / chat)
                            └── HTTP LAN ──> PC (Ollama: Qwen3.8-27B-Ridge)

Three machines to ask which devices are online. This is what happens when I choose my own weekend projects.

Demo

The interface is one HTML page served on the phone by Ruby's TCPServer. Safari displays the page. An ordinary HTML form sends questions. A refresh link updates the display. There is no JavaScript.

The page lists registered and discovered devices, their online status, and the model's availability. The latest reply appears above the question box.

During verification over USB SSH, Ruby on the phone returned:

ruby 4.0.7 (2026-09-29 revision fdc00de497) +PRISM [armv7-darwin10]

An HTTP request from the phone to its own dashboard returned 13 device entries. Eleven entries were online and two were offline. A second request from the phone reached the Mac agent successfully. The agent reported the local model as reachable.

Those two offline entries need a qualification: pc and printer still had placeholder records in my configuration. The result proves the dashboard receives data. It does not prove that my actual PC and a real printer were offline.

Code

The dashboard source is available on GitHub:

• agent/ runs on the Mac. It scans the network, handles commands, and sends questions to the model.
• client/ runs on the phone. It serves the dashboard and talks to the agent.
• config/ holds device records and agent settings.
• deploy/ installs the phone's dashboard service.

The agent and client use Ruby's standard library, with no runtime gems. The tests use Minitest.

How I Built It

The model is Qwen3.8-27B-Ridge, served locally by Ollama on my PC. The Mac agent reaches Ollama over HTTP on the LAN.

The jailbroken phone runs iOS 6.1.6 and my cross-compiled CRuby build. Getting Ruby onto the phone needed changes to CRuby for compatibility with the old iOS SDK. That work belongs to the larger project. This weekend's task was to give Ruby an application.

I chose a web page for the interface because the phone already has Safari and an onscreen keyboard. Ruby serves the page, and a launchd service starts the dashboard. I had already used this approach for a light-meter application on the same phone.

The most useful bug appeared after the connections worked. The agent scanned the network. The model answered questions. But the model knew nothing about the scan.

I asked what devices were on my network. The reply began:

I can’t see your network. On your computer: run arp -a …

Fair answer. I had connected the model without sending the information the model needed.

The fix was to attach the latest device snapshot as context:

def system_prompt
  "You are a LAN overseer. Answer from the device list below only. " \
    "Keep the answer short. Devices: #{device_summary}"
end

After the fix, the recorded answer began with “10 devices online” and listed addresses from the snapshot. The model now had information about my network instead of only my question.

Commands such as ping, scan, wake, and ports go through Ruby command handlers. Free-text questions go to the model. The model explains the supplied device status; it does not choose or execute network commands.

The prompt does not guarantee accurate answers. One later reply suggested that the placeholder printer might have responded on a printer-related port. The supplied context contained no evidence for that explanation.

That is a useful limit to show alongside the working demo. Providing context helps, but the configuration and the answers still need checking.

Why Does Open Innovation Matter?

Open source made both parts possible: adapting Ruby for the phone and running a model on hardware I control.

The phone's Ruby build has no OpenSSL extension. The dashboard uses plain HTTP inside my home LAN. The Mac agent has no authentication, so this prototype belongs on a trusted home network.

Local inference gives this project three useful properties:

• Local data. The application sends device status and questions to my own PC.
• No per-token API fees. I use existing hardware, although running that hardware still uses electricity.
• A replaceable model. I can install another compatible model in Ollama and change model_name in config/agent.yml.

The phone does not need to run the model itself. A small Ruby client is enough to use the model through the Mac agent.

That is enough for this weekend. I started with Ruby running on an old phone and no application in mind. Now the phone has a dashboard, and I have a project to write about.

Eventually, I want to share the wider Ruby-on-3GS story at a Ruby user group, perhaps as my first lightning talk. This dashboard gives me one working example to show.

My best friend seems pleased with the result. He is already thinking about what else to run on the phone.

Comments

[Pawel]

The placeholder printer story is a great illustration of a real limit. The model got the snapshot you gave it, but the snapshot itself had placeholder data, so the answer looked grounded while quietly being invented. Specifying the data is only as good as the data itself. And the 'fair answer' moment is worth underlining: models do not ask for the context they are missing, they just answer without it. Cute project, the 3GS deserved a second act.