One platform.
Nine RFC problem spaces.

The problem: Networking in environments with intermittent connectivity, long delays, frequent partitions, and heterogeneous transports. The Internet's assumption of continuous end-to-end paths breaks down in challenged environments.

The proposed solution: The Bundle Protocol — a new message-oriented overlay with custody transfer, endpoint identifiers, priority classes, fragmentation, and convergence layers.

Adoption status: Limited to NASA deep-space missions (ISS, select probes). Negligible terrestrial adoption after 18 years.

How FrogNet addresses it: FrogNet provides a platform where every capability the RFC specifies — custody transfer, message priority, lifetime management, transport-agnostic convergence — is implementable as application-layer daemon behavior on the platform substrate. The transient database provides persistent store-and-forward. The mesh self-forms and self-heals. When the network partitions, each fragment operates autonomously. When fragments rejoin, they merge. The platform doesn't distinguish between a ten-second outage and a ten-day one.

The problem: HTTP transfers entire responses even when only a small portion has changed. On bandwidth-constrained links, this waste is significant.

The proposed solution: HTTP header extensions (A-IM, IM) to negotiate delta-encoded responses between client and server. The RFC also describes an architecture using interposed proxy pairs to transparently optimize HTTP streams.

Adoption status: Effectively zero. Major browsers never implemented it.

How FrogNet addresses it: The BLDC-1 semantic compression engine implements the interposed proxy architecture the RFC described. The proxy/daemon pair on each node transparently intercepts HTTP traffic and applies a SAME/DIFF/FULL state machine. Unchanged responses are reduced to a 21-byte token. On real traffic across the deployed mesh, FrogNet achieves up to 40x effective bandwidth amplification — far exceeding what RFC 3229 envisioned with simple binary deltas.

The problem: Traditional security models (PKI, certificate authorities) impose costs and complexity that prevent widespread encryption deployment. The result is that most communication falls back to cleartext.

The proposed solution: Trust On First Use (TOFU) — accept and store credentials on initial contact without full authentication, then use cached credentials for subsequent sessions. Prioritize communication over authentication perfection.

Adoption status: Moderate. SSH uses TOFU. Most other protocols still require PKI.

How FrogNet addresses it: FrogNet's security model uses Ed25519 signed runonce commands with TOFU key exchange. Nodes authenticate on first contact and trust from there. WireGuard tunnels provide authenticated encryption on every inter-site link. No certificate authority, no PKI infrastructure, no key management overhead. Security is present by default without impeding communication — exactly what the RFC prescribes.

The problem: Low-Power Wide-Area Networks (LoRa, Sigfox, NB-IoT) have severe constraints: tiny packet sizes, limited throughput, one-way or asymmetric links. Standard IP protocols don't fit.

The proposed solution: A reference architecture for LPWAN networks with gateways, network servers, and application servers.

How FrogNet addresses it: FrogNet's Meshtastic bridge ingests LoRa packets and writes them as sensor entries in the transient database. From that point forward, the data is native to the FrogNet application stack — dashboards, AI hosts, compression engine. The bridge doesn't need to understand FrogNet internals; it writes correctly formatted sensor entries. The semantic compression layer makes subsequent data exchange over constrained links practical by reducing redundant transmissions to 21 bytes.

The problem: IoT devices (microcontrollers, sensors, actuators) operate under severe resource constraints — limited memory, CPU, power, and bandwidth. Existing Internet protocols are too heavy.

The proposed solution: A taxonomy of constrained devices (Class 0, 1, 2) and networks, establishing a common vocabulary for the problem space.

How FrogNet addresses it: ESP32 sensors and actuators write directly to the transient database using simple HTTP POST operations. The platform handles routing, compression, discovery, and data availability across the mesh. A field engineer integrated ESP32 sensors (light sensor, actuator for lamp control) within two days of first contact with the system. The constrained device needs only to write a JSON record — the platform handles everything else.

The problem: Devices on a network need to discover services without manual configuration or a central directory. Traditional DNS requires infrastructure that may not exist.

The proposed solution: mDNS for zero-configuration name resolution on local links. DNS-SD for advertising and discovering services using DNS record types.

How FrogNet addresses it: FrogNet's discovery layer provides service discovery across a multi-site mesh, not just a single local link. The WellKnownSite table maps service names to addresses. Per-domain dnsmasq forwarding rules (generated automatically by the merge process) route DNS queries to the correct gateway. The .frognet TLD provides a private namespace. Node capabilities self-advertise. No central registry — each node knows what it knows and shares what it learns. This extends the mDNS/DNS-SD concept from a single broadcast domain to an arbitrary mesh topology.

The problem: Home networks should be self-configuring, requiring zero manual administration from non-expert users. Devices should discover each other, obtain addresses, and communicate without human intervention.

How FrogNet addresses it: Every FrogNet node creates its own complete TCP/IP network on power-up. DHCP, DNS, routing, service discovery — all automatic. The automated installer gets a new node into the mesh by running a single script. The mesh forms and reforms without manual configuration as nodes join, leave, or move. This is HOMENET's vision applied beyond the home to an arbitrary, potentially global topology.

The problem: IPv6/UDP/CoAP headers are too large for LPWAN networks. Compression is needed, but it must work without complex resynchronization — constrained devices can't handle the overhead.

The proposed solution: A static context shared between endpoints that describes header field values. Fields that match the context are elided entirely; only residual differences are transmitted.

How FrogNet addresses it: BLDC-1's semantic compression uses an analogous concept at the application layer. The proxy/daemon pair maintains a shared context (cached templates and response hashes). When the semantic content matches the cached state, the entire response is elided — replaced by a 21-byte SAME token. SCHC compresses headers; FrogNet compresses entire application-layer exchanges. Both use static/cached context to avoid resynchronization overhead. FrogNet's approach operates at a higher layer but achieves proportionally larger savings because application payloads dwarf headers.