Becky Ecosystem Layers, Right of Passage, and Beckon vs HTTP

The diagram presents the full technical architecture of “Becky,” an open commerce network. It shows multiple stacked layers, each with a clearly defined role, and makes clear that every entity that wants to be part of this network will find a place in one or more of these areas.

Layer Breakdown

At the base sits the Specification and Support Layer, which supplies resources for implementation and testing. Above it are the runtime layers, comprising consumer and provider interfaces, server‑side applications, and routing components. The middle tier is the Underlying Infrastructure, the essential bridge that moves platforms from mere specification compliance to live, transacting entities.

Underlying Infrastructure Details

This middle layer functions like an ISP for internet access, providing the “right of passage” that goes beyond simple protocol implementation. Platforms that have satisfied the specifications are listed in open registries—local, country‑level, and root—making them discoverable to peers. The design mirrors familiar internet concepts such as DNS for addressing and the SSL certificate chain of trust for validation.

Supporting Infrastructure

To accelerate adoption, a supporting ecosystem surrounds the core layers. Certification companies test platforms against the standards and issue digital certificates of compliance. Audit agencies review transaction histories and set compliance benchmarks. System integrators deliver packaged solutions that plug companies into the network quickly. Consulting firms manage network operations, generate demand, and explain benefits, while legal firms handle licensing of the specifications, which are released under a CC BY‑ND license.

Beckon Protocol vs. HTTP

An open commerce network cannot rely on a single specification; it requires multiple layered specifications. Compared with HTTP, Beckon introduces commerce‑aware methods such as Search, Select, Init, Confirm, Cancellation, Order Status, and Tracking, rather than generic GET and POST. Its packet structure uses a context and message instead of HTTP’s headers and body. Beckon enforces an underlying schema that defines all components of a typical commerce transaction, whereas HTTP leaves content schemas largely unspecified. Addressing shifts from DNS to open registries, routing moves from DNS gateways and IP routers to dedicated Beckon Gateways, and trust is established through digital certificates issued by certification agencies rather than SSL certificates with varying validation levels.

Mechanisms in Practice

When a platform passes the “right of passage,” it becomes a live transacting entity on its local network. Open registries list the platform’s endpoints, enabling other participants to locate it. Certification bodies help platforms become “Beckon enabled” by confirming adherence to standardized APIs and language. The commerce‑aware methods and enforced schema give transactions a structured, trustworthy flow, while digital certificates provide the necessary trust foundation for commercial interactions.