Holonia-NearBridge

Holonia’s first runnable foundation: NearBridge lets an iPhone pair with a nearby Mac, invoke a Host-approved model capability, and receive a signed, auditable answer.

Comment

Inspiration

Holonia begins with a broader question: when a person or Agent lacks a capability, how can a request find the right Holon, establish trusted contact, delegate narrowly scoped work, and receive a verifiable result?

The phone in a person's hand is not always the best place to run the strongest available model. At the same time, turning a personal Mac into a generic remote-execution server would create unacceptable risk.

I built NearBridge for OpenAI Build Week 2026 as Holonia's first runnable foundation: a local capability path where discovery remains untrusted, people explicitly approve identity, and the Host - not a remote prompt - decides exactly which capability may run.

What it does

NearBridge consists of native iPhone and Mac apps.

The devices discover one another over Bonjour and Network.framework, but discovery does not establish trust. The user compares the same six-digit verification code and explicitly approves pairing on both devices. NearBridge then establishes a fresh authenticated session carrying signed, expiring, correlated, and replay-aware messages.

After completing a signed Primary Holon contact workflow, the iPhone can send a bounded, non-sensitive plain-text question. The Mac Host selects the implementation and invokes a GPT-5.6 model-only adapter in a separate app-sandboxed XPC service.

The Mac signs the typed result. The iPhone verifies the sender, session, expiry, signature, and correlation before displaying it, then returns an acknowledgement. Both devices expose a correlated execution receipt and sanitized diagnostics.

How I used OpenAI

GPT-5.6 is the real model used in the demonstrated iPhone-to-Mac path.

The isolated Mac runner calls the OpenAI Responses API through a fixed model-only request:

  • store: false
  • no tools
  • bounded input and output
  • fixed approved HTTPS endpoint
  • redirect rejection
  • privacy-preserving session safety identifier

The API key is entered only in the Mac app and stored in Mac Keychain. It is never sent to the iPhone or included in model input, logs, or sanitized diagnostic exports.

How I built it

NearBridge is implemented with Swift and SwiftUI for iOS and macOS.

Its current Host-controlled platform layers include:

  1. Bonjour discovery and Network.framework transport
  2. Host-managed stable identities and explicit pairing
  3. Fresh authenticated sessions
  4. Signed and typed workflow messages
  5. Versioned HolonManifest definitions
  6. A capability registry and explicit execution profiles
  7. Separate app-sandboxed XPC model runners
  8. Signed results, acknowledgements, execution receipts, and sanitized diagnostics

The remote capability remains behind a stable interface:

holonia.capability.primary-holon.text-insight.v1

The iPhone cannot choose the provider, model, endpoint, credential, runtime, or tools. Those decisions remain under Mac Host control.

How I used Codex

I used Codex as my engineering collaborator throughout Build Week.

It helped me turn the security and design brief into incremental NB checkpoints, implement native discovery and pairing, build authenticated message and capability state machines, introduce manifests and adapter execution profiles, separate the model runners into XPC services, diagnose real-device Bonjour, signing, Keychain, bundle, and XPC-registration failures, and create tests, runbooks, reviewer diagnostics, and the final video.

The repository preserves this process through incremental commits, checkpoint documentation, physical-validation records, and tags.

Challenges I ran into

The hardest problem was not transferring text between two devices. It was preserving the distinction between discovering a nearby service and trusting an identity, then binding every later action to a fresh authenticated session.

Physical Apple-device testing exposed issues that simulations could not prove: Local Network authorization, Keychain access, application signing, bidirectional connection ownership, XPC embedding, and XPC service registration.

The first real OpenAI attempt failed safely because the XPC service was not registered correctly. Structured diagnostics identified the bootstrap failure without exposing the API key. After correcting the XPC bundle configuration and rebuilding the Mac app, the same physical path succeeded.

Accomplishments I am proud of

  • Real iPhone-to-Mac local discovery and explicit pairing
  • Authenticated and signed bidirectional messaging
  • A complete Primary Holon contact and capability workflow
  • A Mac-selected GPT-5.6 model-only adapter
  • A separate XPC runner with no file, shell, workspace, Git, device-control, or dynamic-tool interface
  • A real answer returned to and verified by an iPhone
  • Correlated receipts and privacy-preserving diagnostic export
  • 54 passing shared tests and successful Mac and generic iOS device builds
  • Physical validation on a real iPhone and Mac

What I learned

Local discovery is useful transport metadata, but it is not authentication.

A model or adapter should not gain authority simply because it claims to be sandboxed. The Host must define the interface, credential source, network profile,

Built With

  • api
  • bonjour
  • codex
  • cryptokit
  • framework
  • gpt-5.6
  • ios
  • keychain
  • macos
  • network.framework
  • openai
  • responses
  • security
  • swift
  • swiftui
  • xpc
Share this project:

Updates