🪐

Saturn Concept Ladder

From "why does this exist?" to "here's what it proves." Click any rung to expand. Filter by reading path below.

0

The Problem ▼

AI access is gatekept by individual subscriptions and broken credential management.

Key Ideas

  • GenAI costs $20-100/month per person, creating an access gap that tracks existing inequality
  • Every app configures AI independently — API keys pasted into env files, config UIs, CLI flags
  • Static API keys leak constantly: 100K+ secrets found in public GitHub repos (Meli 2019)
  • Fragmentation: voice typing, coding assistant, chat UI all need separate keys for the same model
Imagine if every application on your laptop needed its own WiFi password, and that password was a credit card number.
You get this when you can explain why "just paste your API key" fails at scale

Moons Files

voice/motivation.md concepts/api-key-leakage.md papers/costa-2024.md papers/meli-2019.md
1

How Networks Already Work ▼

Networks already auto-configure some things — understand the substrate before seeing what Saturn adds.

Key Ideas

  • DNS resolves human names to IP addresses via a centralized hierarchy
  • DHCP auto-assigns IPs when devices join — zero-config for users, but needs a server
  • Multicast sends to a group address (224.0.0.251) — everyone listening on the LAN hears it
  • DNS and DHCP need infrastructure. Multicast is peer-to-peer
DHCP is the front desk assigning room numbers. DNS is the phone book. Multicast is shouting in the lobby — everyone in earshot hears you.
You get this when you can explain why DHCP needs a server but multicast doesn't

Moons Files

concepts/dhcp.md
2

Zero-Config Discovery ▼

Devices find each other's services on a local network with zero infrastructure, using mDNS and DNS-SD.

Key Ideas

  • mDNS (RFC 6762): DNS without a server. Queries go to multicast; devices answer for their own .local names
  • DNS-SD (RFC 6763): advertises services. PTR = "I exist," SRV = "my address:port," TXT = "my details"
  • TXT records: key-value pairs up to 255 bytes — where service metadata lives
  • This is how your laptop finds printers, AirPlay speakers, and Chromecasts
  • Cross-platform: Bonjour (macOS/Windows), Avahi (Linux)
mDNS is name tags at a party. DNS-SD is those name tags also listing your skills. "Hi, I'm LaserJet.local, I do _ipp._tcp, and I support color and duplex."
You get this when you can trace how a laptop discovers a printer via mDNS + DNS-SD with zero setup

Moons Files

concepts/mdns.md concepts/dns-sd.md papers/guttman-2001.md papers/siddiqui-2012.md
3

The AI Landscape ▼

AI is delivered as cloud APIs behind per-user keys, with a growing local alternative and a de facto standard protocol.

Key Ideas

  • OpenAI-compatible API: REST at /v1/chat/completions — the de facto standard adopted by dozens of providers
  • Cloud AI: GPT-4, Claude, Gemini — powerful but requires account + API key + payment
  • Local AI: Ollama, llama.cpp, vLLM — no key needed but requires setup and hardware
  • Each application configures its own AI backend independently — massive duplication of effort
It's as if every web browser needed its own ISP subscription. Chrome on Comcast, Firefox on AT&T, Safari on Verizon — all for the same internet.
You get this when you can explain what an OpenAI-compatible endpoint is and why both cloud and local models implement the same interface

Moons Files

concepts/openai-api.md papers/syed-2025.md concepts/voice-typing.md
4

The Gap — Why Not Just Use X? ▼

Existing discovery protocols were considered and rejected. Nothing currently handles AI service discovery.

Rejected Alternatives

  • UPnP/SSDP: too much scope (device control, media, NAT traversal), terrible security record
  • DLNA: UPnP media-only profile, consortium defunct since 2017
  • WS-Discovery: SOAP/XML overhead, enterprise-oriented, no consumer adoption
  • NetBIOS: Windows-only legacy, no cross-platform story
  • P2P/DHT (Chord4S): elegant for WAN, overkill for LAN — mDNS already solves local
  • BeyondCorp: requires centralized identity infrastructure — opposite of zero-config
mDNS/DNS-SD is the right mechanism but nobody defined a service type for AI. Saturn fills that gap — like how _ipp._tcp was defined for printers.
You get this when you can explain why Saturn chose mDNS over UPnP and why DHTs are wrong for LAN discovery

Moons Files

concepts/upnp.md concepts/dlna.md concepts/ws-discovery.md concepts/netbios.md concepts/beyondcorp.md
5

Saturn's Core Insight ▼

A beacon announces AI service metadata over mDNS — it broadcasts credentials but never touches API traffic.

Key Ideas

  • Beacon architecture: register under _saturn._tcp.local., broadcast endpoint URLs, API types, and credentials via TXT records
  • "Announce, don't proxy": the beacon's job ends at advertisement. Users connect directly to the backend
  • No traffic inspection — the beacon never sees prompts or responses
  • Three deployment types: cloud (ephemeral keys), local (Ollama/etc.), network (shared LAN services)
  • Beacon down = no new discovery, but existing connections keep working
A beacon is a signpost, not a tunnel. It says "the restaurant is that way and here's a guest pass" — it doesn't carry your food.
You get this when you can explain the difference between a beacon and a proxy, and why Saturn chose beacons

Moons Files

concepts/beacons.md voice/interview-2.md voice/meeting-log.md
6

Saturn's Protocol ▼

The concrete specification — service type, TXT record schema, and discovery flow.

The Spec

  • Service type: _saturn._tcp.local.
  • Required TXT: version, deployment (cloud|local|network), api_type, api_base, priority, features
  • Beacon-only: ephemeral_key, rotation_interval
  • Optional extensions: models, capabilities, context, cost
  • Priority: lower number = higher priority, admin-controlled routing preference
  • Flow: Browse _saturn._tcp → resolve instances → read TXT → connect to api_base
If beacons (Rung 5) are the concept, this rung is the API spec. Like HTTP defined verbs and headers, Saturn defines the service type and TXT fields.
You get this when you could write a minimal client that browses, reads TXT records, and makes an API call

Moons Files

concepts/priorities.md thesis.tex — Tables 3.1, 3.2
7

Making Keys Safe ▼

Ephemeral keys rotate on short timers — leaked credentials expire before they're useful.

Key Ideas

  • Ephemeral keys: 10-minute lifetime, 5-minute rotation, overlap window for zero-downtime
  • Lifecycle: create via provider API → broadcast in TXT → rotate → delete old key → delete on shutdown
  • Kerberos parallel: distribute time-limited credentials for session establishment
  • BeyondCorp contrast: Google needs centralized identity (certs, SSO). Saturn trusts the network boundary instead
  • Known risks: LAN eavesdropping, 59% of mDNS names leak real names, AP isolation blocks multicast
  • STRIDE analysis: spoofing, tampering, repudiation, info disclosure, DoS, elevation of privilege
A hotel key card that expires every 10 minutes. Even if someone photographs it, by the time they reach the door, the lock has changed.
You get this when you can explain why 10-min keys beat static keys, and what attacks Saturn doesn't prevent

Moons Files

concepts/ephemeral-keys.md concepts/beyondcorp.md concepts/api-key-leakage.md papers/kaiser-waldvogel-2014a.md
8

Real Implementations ▼

Six working components across four languages prove Saturn isn't just a protocol spec.

The Six Components

  • Core Python — reference server + client discovery library
  • Saturn Router (Rust/OpenWRT) — GL.iNet travel router as physical beacon
  • AI SDK Provider (TypeScript) — Vercel AI SDK integration for Next.js
  • Open WebUI Plugin — zero-config model switching in popular chat UI
  • Saturn MCP Server — AI coding assistants discover backends via MCP
  • VLC Extension (Lua + FastAPI) — media player gets AI via Saturn discovery
Python, Rust, TypeScript, Lua. Server-side, client-side, embedded, plugin. Each proves a different facet — like testing a lock with six different keys.
You get this when you can explain which component demonstrates which claim, and why diversity matters

Moons Files

code/python_package_claims.md code/saturn-router.md code/ai-sdk-provider-saturn.md code/owui-saturn.md code/saturn-mcp.md code/vlc-extension.md
9

The Thesis Claims ▼

Everything converges into three testable claims — Saturn's contribution to knowledge.
Claim 1: Zero-config AI provisioning is feasible via mDNS/DNS-SD

Evidence: Rung 2 (mDNS works) + Rung 6 (protocol spec) + Rung 8 (six implementations) → it's not just feasible, it's built. Key papers: Guttman 2001, Siddiqui 2012, Siljanovski 2014.

Claim 2: Network-provisioned AI reduces total configuration effort

Evidence: Rung 0 (fragmentation) + Rung 5 (beacon model) + Rung 8 (real apps) → measured reduction via configuration-work metric. Key papers: Costa 2024, Bassignana 2025, Gabriel 2024.

Claim 3: Security trade-offs are known and addressable

Evidence: Rung 7 (ephemeral keys, threat models) + Rung 4 (BeyondCorp contrast) → not "Saturn is secure" but "Saturn's risks are understood." Key papers: Kim & Reeves 2020, Kaiser & Waldvogel 2014a/b, Meli 2019.

You get this when you can present Saturn's contribution in three sentences, citing specific evidence for each claim

Moons Files

claims/claim-1.md claims/claim-2.md claims/claim-3.md claims/evidence-matrix.md