Virtual Fiber Internet Proof

Purpose

This instrument turns the Virtual Fiber transport architecture into a bounded, physically testable application.

A remote relay deterministically generates one 7.5 KB object and divides it into eighty 96-byte source blocks. The phone receives paced systematic symbols through an ordinary HTTPS stream. A second Internet-connected device receives independent repair symbols from the relay and renders them as a high-contrast optical carrier. The phone camera decodes those frames and feeds both paths into the same generation decoder.

The run completes only when the phone reconstructs the original byte object and matches the relay-provided SHA-256.

Why the direct lane is paced

The public proof deliberately spaces direct symbols by 250 milliseconds. This is not a claim about the site's natural download speed. It creates a controlled, visible baseline that ordinary phone and laptop cameras can supplement with a conservative optical channel.

The first question is not whether a commodity screen already rivals fiber. It is whether a valid optical symbol can advance the same Internet-originated object, shorten completion, survive optical loss without freezing the ordinary path, and produce the identical verified bytes.

Two-device procedure

1. Open the instrument on a desktop or laptop and select Desktop emitter.
2. Leave that device on Ethernet or Wi-Fi and start the optical carrier.
3. Open the same instrument on a phone, select Phone receiver, and enter the displayed session code.
4. Run the direct-only baseline.
5. For the strongest aggregation test, disable phone Wi-Fi so the phone uses cellular service while the desktop retains its independent backhaul.
6. Point the phone camera at the complete optical square and run the hybrid test.
7. Download the generated JSON receipt.

The relay salts and hashes each request's public egress address into a short path fingerprint. Raw IP addresses are not displayed or written into the receipt. Different fingerprints support the bounded observation that the phone and emitter reached the relay through different public egress paths.

Implemented mechanism

The public build includes:

• one deterministic relay object per session;
• eighty source blocks and generation-level binary elimination;
• systematic HTTPS symbols;
• dense repair symbols emitted through a custom VFF1 optical frame;
• a 72×72 physical field with duplicated 2×2 payload cells;
• CRC-32 frame rejection;
• quarter-turn orientation recovery;
• camera capture with a manually aligned square observation region;
• direct-only, camera-hybrid, and explicitly non-evidentiary digital-loopback modes;
• client-side SHA-256 reconstruction verification;
• baseline, hybrid, path, and symbol-contribution telemetry;
• a downloadable result receipt;
• and a web app manifest plus service worker for installation where supported.

What the demonstration can prove

A successful hardware run can establish, for this bounded object and environment, that:

• the phone completed the same object faster after accepted optical repair symbols were added;
• the optical path contributed innovative generation rank rather than decorative activity;
• covering or losing the optical carrier reduced capacity without invalidating the ordinary stream;
• direct and optical frames reconstructed the same generation;
• and the completed bytes matched the server's SHA-256.

When the phone uses cellular and the emitter uses a distinct broadband route, different path fingerprints additionally support a genuine independent-backhaul demonstration.

What it does not prove

This instrument does not establish:

• that every Internet connection becomes faster;
• that a phone camera equals physical fiber;
• that the observed speedup persists without the controlled direct pacing;
• that two paths behind one saturated upstream bottleneck create new upstream capacity;
• that the custom optical codec is optimal;
• that arbitrary operating-system traffic is already accelerated;
• or that a browser demonstration substitutes for Android VpnService, Apple Network Extension, desktop TUN, relay congestion control, or production security review.

Product path

The browser app proves the prerequisite transport shape. A system-wide product would install a local virtual network interface and send eligible traffic through a Virtual Fiber relay. Nearby desktops, televisions, or dedicated display tiles could join as blind optical gateways. Applications would continue to see one connection while the client schedules ordinary and optical-coded subflows beneath them.

The staged product path is:

1. bounded Internet object proof;
2. application-specific download accelerator;
3. browser or file-transfer proxy;
4. native mobile and desktop tunnel;
5. multi-emitter and dedicated optical hardware.

Evidence boundary

The instrument code and deterministic protocol tests support IMPLEMENTED for the bounded software mechanism. No public camera result is promoted by the existence of the interface. A hardware run remains AWAITING_HUMAN_REVIEW until its receipt, environment, screen recording, limitations, and invalid-condition checks are reviewed under b17-virtual-fiber-internet-proof.