Internet Engineering Task Force L. Reilly Internet-Draft Independent Intended status: Informational July 24, 2026 Expires: January 25, 2027 Web4: An Agentic, Verifiable Internet Architecture and the Project Orion Reference System draft-reilly-web4-orion-00 Abstract This document defines Web4, an architectural model for an agentic, cryptographically verifiable Internet in which autonomous AI agents operate as first-class participants alongside humans, and every published artifact carries independently checkable proof of origin, integrity, and time. Web4 is realized through the Reilly Protocol Suite, a set of eighteen active IETF Internet-Drafts spanning permanence, integrity, agent orchestration, defense, and human epistemic autonomy. This document also specifies Project Orion, the live reference implementation that unifies the full suite behind autonomous agents on both backend and frontend, verified against three independent Internet-Draft distribution points, and operating publicly at https://project-orion-production.up.railway.app/. A step-by-step implementation guide is provided. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 25, 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction 2. Terminology 3. The Web4 Architecture Model 3.1. Layer 1: Permanence 3.2. Layer 2: Integrity 3.3. Layer 3: Agentic Operation 3.4. Layer 4: Defense 3.5. Layer 5: Human Sovereignty 4. Utilization of the Reilly Protocol Suite 5. Project Orion Reference Implementation 5.1. Draft Sources and Triple Verification 5.2. Autonomous Agent Architecture 5.3. Human-Oversight and Autonomous Modes 6. Implementation Guide 6.1. Phase 1: Source Aggregation 6.2. Phase 2: Triple-Mirror Verification 6.3. Phase 3: Permanence Anchoring 6.4. Phase 4: Agent Backend 6.5. Phase 5: Agentic Frontend 6.6. Phase 6: Oversight Toggle 6.7. Phase 7: Deployment and Continuous Operation 7. Security Considerations 8. IANA Considerations 9. Informative References Author's Address 1. Introduction Web 1.0 delivered readable documents; Web 2.0 delivered writable, social platforms; Web 3.0 introduced decentralized ownership. None of these generations answers two questions now central to an Internet populated by AI agents: (1) can any artifact's origin, integrity, and timestamp be verified without trusting its host, and (2) can autonomous agents operate web systems continuously while humans retain meaningful oversight and epistemic autonomy? Web4 is defined here as the architectural generation that answers both. Its two invariants are: o Verifiability by default: every artifact is anchored via Dual-Layer Digital Permanence (Bitcoin blockchain timestamping plus DOI archival), and served content is cross-checked against multiple independent distribution points. o Agency with sovereignty: autonomous agents maintain, heal, and present the system under Machine-Web Symbiosis, while humans retain Cognitive Sovereignty over agent-curated content and a switchable human-oversight mode. The Reilly Protocol Suite supplies the protocol substrate; Project Orion (Section 5) is the operating proof. 2. Terminology Web4: The agentic, verifiable Internet architecture defined in this document. Project Orion: The unified reference implementation of Web4, deployed at project-orion-production.up.railway.app, covering all eighteen active drafts of the Reilly Protocol Suite with fully autonomous agents on backend and frontend. Dual-Layer Digital Permanence: The methodology of anchoring an artifact simultaneously to the Bitcoin blockchain (via OpenTimestamps) and to a persistent DOI archive (Zenodo), optionally supplemented by IPFS content addressing. Machine-Web Symbiosis (MWS): The operating relationship in which autonomous agents and web infrastructure co-maintain a system, extending Licklider's 1960 man-computer symbiosis framing [MWS]. Cognitive Sovereignty: The property that humans retain epistemic autonomy over agent-curated content, supported by the Curation Disclosure Record (CDR) and Sovereignty Fallback [COGSOV]. Triple Verification: Cross-checking each Internet-Draft against three independent distribution points: the IETF archive, the FUNET mirror (nic.funet.fi), and the OTEnet mirror (ftp.otenet.gr). 3. The Web4 Architecture Model Web4 is organized into five layers. Each layer is normatively realized by one or more drafts of the suite (Section 4). 3.1. Layer 1: Permanence All artifacts are anchored using Dual-Layer Digital Permanence. An artifact without a blockchain timestamp and archival DOI is not Web4-compliant. Realized by the REM Protocol [REM] and applied uniformly across the suite. 3.2. Layer 2: Integrity Domain-specific integrity assurances for content and institutions: web content proof (WebProof), banking integrity (RBIP), government integrity (RGIP), and ledger/token integrity (RLT Genesis, SkyLedger). 3.3. Layer 3: Agentic Operation Autonomous agents perform monitoring, compliance, evaluation, and self-healing: PLPES (Protocol Layer Prompt Engineering), CTS, AIMED and AIMED-EVAL, UAEMF, and RMRP. MWS defines the governing symbiosis model. 3.4. Layer 4: Defense Resilience and moving-target defense: RRP (resilience), RSP (sentinel/AI integrity), and HDRP [HDRP], whose hypercube shard topology with rotation-based moving target defense protects data at rest against static-target attacks. 3.5. Layer 5: Human Sovereignty Cognitive Sovereignty [COGSOV] governs how agent-curated output is disclosed to humans via the CDR, and guarantees a Sovereignty Fallback to non-curated sources. Project Looking Glass [LG] integrates all five layers into a single self-healing deployment pattern. 4. Utilization of the Reilly Protocol Suite The following table maps the eighteen active drafts to Web4 functions. +---------------------+--------+----------------------------------+ | Draft / Protocol | Layer | Web4 Function | +---------------------+--------+----------------------------------+ | REM Protocol | 1 | Permanence anchoring; REMID | | | | verification records | | WebProof | 2 | Verifiable web content | | RBIP | 2 | Banking integrity | | RGIP | 2 | Government integrity | | RLT Genesis | 2 | Token/ledger genesis integrity | | SkyLedger | 2 | Distributed ledger services | | PLPES | 3 | Protocol-layer prompt | | | | engineering; compliance engine | | CTS | 3 | Trust/compliance services | | AIMED | 3 | AI model evaluation/description | | AIMED-EVAL | 3 | Evaluation harness | | UAEMF | 3 | Unified agent evaluation and | | | | management framework | | RMRP | 3 | Monitoring and reporting | | MWS | 3 | Machine-Web Symbiosis model | | RRP | 4 | Resilience | | RSP | 4 | Sentinel / AI integrity | | HDRP | 4 | Hypercube rotation defense | | Cognitive | 5 | CDR disclosure; Sovereignty | | Sovereignty | | Fallback | | Looking Glass | 1-5 | Integrative self-healing pattern | +---------------------+--------+----------------------------------+ Live systems demonstrating suite utilization include the REM Protocol 14-agent autonomous pipeline (rem-protocol-agent-production.up.railway.app) and the HDRP site (hdrp-hypercube-site-production.up.railway.app). 5. Project Orion Reference Implementation Project Orion is publicly deployed at: https://project-orion-production.up.railway.app/ The application ("Project Orion -- The Reilly Protocol Suite") renders the eighteen Internet-Drafts as a living constellation: each draft is a selectable star exposing its status, brief, permanence verification, and source links. Companion panels include the Agent Constellation (live agent state), Pending Approvals (oversight-mode action queue), Mission Log, and Suite Insight (a cartographer agent mapping the dependency graph across drafts). 5.1. Draft Sources and Triple Verification Project Orion aggregates the suite from the author's IETF Datatracker author profiles and performs Triple Verification of each draft against: 1. The IETF Internet-Drafts archive (www.ietf.org/archive/id/) 2. The FUNET mirror (nic.funet.fi) 3. The OTEnet mirror (ftp.otenet.gr, Greece) A draft is presented as verified only when all reachable distribution points agree. At initial deployment (July 23, 2026) Project Orion confirmed 18 of 18 drafts live on the Datatracker. 5.2. Autonomous Agent Architecture Agents operate on both tiers: o Backend agents: source polling, Triple Verification, permanence checks (OpenTimestamps proofs, Zenodo DOIs), health monitoring, and self-healing per the Looking Glass pattern. o Frontend agents: presentation, summarization, and navigation of the suite for human visitors, with curation disclosed via CDR per Cognitive Sovereignty. 5.3. Human-Oversight and Autonomous Modes The system exposes a mode toggle: o Autonomous mode: agents act on findings (re-verification, content refresh, healing) without human approval. o Human-oversight mode: agents propose actions; a human operator approves or rejects via the Pending Approvals queue. This is the Web4 embodiment of the Sovereignty Fallback at the operations level. The HUMAN OVERSIGHT / AUTONOMOUS toggle is exposed directly in the deployed interface, and all agent activity is surfaced in the Mission Log. 6. Implementation Guide The following seven phases reproduce a Project Orion class Web4 deployment. 6.1. Phase 1: Source Aggregation 1. Enumerate the target draft set from the author's Datatracker profile(s). 2. Fetch canonical text from the IETF archive (https://www.ietf.org/archive/id/-.txt). 3. Store draft name, revision, and SHA-256 digest of each file. 6.2. Phase 2: Triple-Mirror Verification 1. Fetch the same draft from the FUNET mirror and the OTEnet mirror. 2. Compare digests across all three sources. 3. Mark VERIFIED on full agreement; mark DEGRADED (with the agreeing subset) if a mirror is unreachable; mark FAILED and quarantine on digest mismatch. 4. Re-run on a fixed interval and on any upstream change event. 6.3. Phase 3: Permanence Anchoring For each verified artifact: 1. Create an OpenTimestamps proof anchoring its digest to the Bitcoin blockchain. 2. Deposit the artifact and metadata to Zenodo, obtaining a DOI. 3. Optionally pin to IPFS for content-addressed retrieval. 4. Record the resulting REMID verification record per the REM Protocol. 6.4. Phase 4: Agent Backend 1. Implement agents as independent workers: fetcher, verifier, permanence auditor, health monitor, healer, reporter. 2. Coordinate via a shared state store; every agent action is logged with timestamp and rationale. 3. Apply UAEMF/RMRP monitoring so agent behavior is itself evaluated and reported. 6.5. Phase 5: Agentic Frontend 1. Serve the suite as a navigable application; frontend agents generate summaries and answer visitor queries. 2. Attach a Curation Disclosure Record to agent-generated presentation, identifying source drafts and transformations. 3. Always provide a Sovereignty Fallback link to the raw, verified draft text. 6.6. Phase 6: Oversight Toggle 1. Implement a global mode flag (AUTONOMOUS / OVERSIGHT). 2. In OVERSIGHT, agent-proposed actions enter an approval queue with human accept/reject; in AUTONOMOUS, actions execute and are reported after the fact. 3. Mode changes are themselves logged and permanence-anchored. 6.7. Phase 7: Deployment and Continuous Operation 1. Publish the repository to GitHub; deploy via Railway (or an equivalent PaaS) with automatic redeploy on push. 2. Confirm end-to-end status: all drafts VERIFIED, permanence records present, agents reporting healthy. 3. Operate continuously: scheduled re-verification, self-healing on failure per the Looking Glass pattern, and periodic permanence audits. 7. Security Considerations Triple Verification reduces reliance on any single distribution point but assumes mirror independence; operators SHOULD monitor mirror provenance. Blockchain timestamps prove existence-by-time, not authorship; authorship claims rest on the archival (DOI) layer and IETF submission records. Autonomous agents acting on external content are exposed to prompt-injection style inputs; frontend agents MUST treat fetched content as data, and the OVERSIGHT mode provides a containment control. Data-at-rest protections SHOULD apply HDRP rotation-based moving target defense. Availability of third-party services (mirrors, Zenodo, IPFS gateways, PaaS) is outside the operator's control; the DEGRADED verification state exists for this reason. 8. IANA Considerations This document has no IANA actions. 9. Informative References [REM] Reilly, L., "REM Protocol", draft-reilly-rem-protocol, September 2025. [MWS] Reilly, L., "Machine-Web Symbiosis (MWS)", draft-reilly-mws-00, 2026, . [COGSOV] Reilly, L., "Cognitive Sovereignty", draft-reilly-cogsov-00, July 2026, . [LG] Reilly, L., "Project Looking Glass", draft-reilly-looking-glass-00, July 2026. [HDRP] Reilly, L., "Hypercube Data Rotation Protocol (HDRP)", draft-reilly-hdrp-00, July 2026, . [ORION] Reilly, L., "Project Orion -- The Reilly Protocol Suite", reference implementation, July 2026, . Author's Address Lawrence John Reilly Jr. Email: lawrencejohnreilly@gmail.com