What is the announced IEEE 2874?
In 2025, the IEEE – the same body that standardized Wi-Fi and Bluetooth – approved a new standard called IEEE 2874: the Spatial Web Protocol.
The idea is big. The internet, as we know it, was built in two waves:
Wave 1 – TCP/IP (1970s). Computers learned to talk to each other. Networks connected. Data moved.
Wave 2 – HTTP and HTML (1990s). The World Wide Web appeared. Suddenly anyone could publish a page, click a link, and browse information. The web was born – as a network of documents.
Wave 3 – IEEE 2874 (2025). The Spatial Web. A proposed new protocol layer where AI agents, robots, smart devices, digital twins, and real-world places can all find each other, exchange data, and act – not just display pages.
The standard defines three components:
- HSML (Hyperspace Modeling Language) – a way to describe things and actions, like nouns and verbs for machines.
- HSTP (Hyperspace Transaction Protocol) – rules for how those things interact.
- UDG (Universal Domain Graph) – a global map of identities and relationships.
The promise: a city’s traffic system could talk to your car. A factory’s digital twin could negotiate with a supply chain AI. A medical sensor could alert an emergency system – all through a shared, standardized layer.
It sounds transformative. But there is a problem hidden in the design.
The Problem IEEE 2874 Inherits
The web was built for documents. Pages. Text with links. When people started building applications on the web – email clients, spreadsheets, design tools – they had to work around a system that was never meant for software.
Every web app you use today – Gmail, Figma, Notion – is technically a document pretending to be a program. It runs inside window and document, objects designed for pages, not applications. Decades of frameworks, bundlers, and tooling exist to paper over this mismatch.
IEEE 2874 risks repeating the same mistake, one level up. Instead of fixing the runtime – the place where software actually executes – it adds another protocol layer on top of HTTP. Another abstraction. Another specification that sits beside the actual code, rather than inside it.
History suggests this doesn’t scale. The Internet Engineering Task Force has seen many grand architectural proposals. The ones that succeed are usually small, incremental, and backward-compatible. The ones that try to redesign everything from the top down tend to remain academic.
What Warp Apps Are
Warp Engine takes a different approach. Instead of adding a new protocol to the internet, it introduces a runtime where applications execute.
What is a runtime? It’s the environment your code runs inside. In a browser, that runtime is the page – window, document, the DOM. Every web app inherits this page-based environment, and every web framework exists to work around its limitations.
Warp adds another apstraction in the page. An app running in Warp does not use window or document. Instead, it gets two things:
app– your application context. It holds your window on screen (app.win), your content area (app.body), and your state. It’s yours. No other app can see it.dom– your scoped DOM.dom.queryfinds elements inside your app.dom.onattaches events inside your app. It cannot reach outside your window.
And one rule:
this– is your public API. Any method you put onthiscan be called by other apps, or by an AI agent. Nothing else leaks out.
That’s the entire contract. Two objects and a this. No framework. No bundler. No imports. No build step.
What does this mean in practice?
An app is a folder. It contains an HTML file (your interface), an optional CSS file (your styles), and a JavaScript file (your logic). The engine takes care of everything else: creating your window, injecting your HTML, scoping your styles, isolating your code, and registering your public API.
Apps are lazy – they cost nothing until someone asks for them. Calling await warp.app("Calculator") instantiates the Calculator app on demand. If it’s already running, you get the existing instance. If another app calls it, same thing. Apps are singletons with public interfaces.
The Engine is what makes this possible. It provides:
- Windows that you can drag, resize, minimize, maximize, and anchor to each other – a real windowing system, not CSS tricks.
- A shared Store that synchronizes state across browser tabs in real time, via a SharedWorker.
- A Drive system with three backends: in-memory objects, IndexedDB for persistence, and HTTP for remote servers – all with the same API.
- A File abstraction that wraps any binary data with metadata, lifecycle events, and serialization.
- Layouts – portable zip bundles that contain apps, file type definitions, data types, and search providers. Drop a layout in, and everything it contains is available.
- A typed data system called Brands, Items, and Slots – where data carries its own type identity, and apps declare what types they accept. Data routes itself to the right app automatically.
The engine runs inside a browser. No plugin. No installation. No new protocol. Just JavaScript, served over plain HTTP.
Warp Apps vs. IEEE 2874
IEEE 2874 and Warp Engine are trying to solve the same fundamental problem: the web was designed for documents, and the future needs it to work for programs, agents, and machines. But they attack it from opposite ends.
IEEE 2874 starts at the protocol level. It defines new message formats (HSML), new transaction rules (HSTP), and a new global identity graph (UDG). It assumes that if you standardize how entities describe themselves and communicate, applications will follow.
Warp starts at the runtime level. It assumes that if applications can actually run as programs – with real identity, public APIs, and typed data – the protocol is just transport. HTTP carries it fine.
Here is how they compare on the capabilities IEEE 2874 claims to enable:
| Capability | IEEE 2874 approach | Warp approach |
|---|---|---|
| Named, discoverable entities | HSML definitions in a new markup language | warp.app("Name") – apps are named, registered, and callable |
| Public interfaces (verbs) | HSTP transaction types | this.methodName = function(...) – plain JavaScript |
| Typed data exchange | UDG ontology | Brands – data carries its type, apps declare what they accept |
| Automatic data routing | UDG + HSTP negotiation | warp.inspect(data) – routes data to every app that handles its type |
| Agent interaction | Agents speak HSTP | Agents call warp.app("X") and invoke this.* methods – no new protocol |
| Cross-instance sync | Not specified (deferred to transport) | SharedWorker Store – real-time, cross-tab, built in |
| Portability | Standard compliance | Layouts – zip bundles that carry everything, run anywhere |
What Warp does that IEEE 2874 cannot:
Warp apps run today. In any browser. Over plain HTTP. No new infrastructure, no new DNS-like system, no global graph database. An AI agent can generate a Warp app from scratch – HTML, CSS, JS in a folder – and the engine runs it immediately. That feedback loop (agent writes code, runtime executes it, user sees results) is what makes the system practical.
What IEEE 2874 addresses that Warp does not (yet):
Cross-origin discovery. If two Warp engines run on different servers, they don’t yet know about each other. IEEE 2874’s UDG is designed for this – a global registry of entities. Warp currently works within a single origin (one website, multiple tabs). Federation – Warp engines finding and calling each other across the internet – is a future layer.
Identity and authentication at the protocol level. IEEE 2874 bakes identity into HSTP. Warp currently inherits whatever authentication the hosting website uses. A dedicated identity layer is not yet built.
The philosophical difference:
IEEE 2874 says: define the protocol, and applications will be built to speak it.
Warp says: fix the runtime, and the protocol is just HTTP carrying function calls.
History favors the second approach. TCP/IP won because it was simple and deployable, not because it was the most theoretically complete. HTTP won because it was easy to implement, not because it solved every problem. The web’s application layer emerged organically from JavaScript running in browsers – not from a top-down standard.
Warp bets that the same pattern holds for the next evolution: make programs first-class citizens of the web, give them identity and typed data, and let AI agents compose them. The internet doesn’t need a third foundational protocol. It needs its first real application runtime.