Skip to content
Boredgolem IMWA Lab

HOW IMWA WORKS

The URL stays universal. The capability path gets specific.

IMWA adds a broker between your WordPress experience and the device. The broker discovers available providers, checks consent and license state, then routes a bounded job through the best eligible path.

Six checks before hardware work begins.

  1. Domain lease

    The parent validates a signed lease bound to the normalized WordPress origin and installation ID.

  2. Runtime election

    One owner controls the manifest, root service worker, install surfaces, and browser push path.

  3. Consent grant

    The requested purpose, capability, precision, duration, and viewer are checked before a provider runs.

  4. Provider discovery

    The broker ranks registered browser, Shortcut, native, and edge providers for the current device.

  5. Signed exchange

    Short-lived tickets and replay-resistant events connect the provider to the external data plane.

  6. Truthful projection

    WordPress receives only bounded state such as last update, verified NFC action, or notification outcome.

The same JavaScript request can land on a different implementation.

RequestWebBridgeEdge
location.watch()Foreground geolocationShortcut or companionIndependent GNSS
nfc.scan()Signed NFC URL entryCore NFC companionNFC reader gateway
ble.connect()Compatible Web BluetoothCore Bluetooth companionBLE gateway
notifications.send()Web push and in-appCompanion notificationDevice signal or command

Extend the edge without forking the foundation.

Parent-only security boundaryLicensing, runtime ownership, schemas, migrations, signing, and updates remain final.

Child-owned additionsRegister providers, notification sources, admin sections, presentation, and site-specific adapters.

Contribution-readyExtensions can be reviewed and shared without editing the commercial parent plugin.

Install the parent. Activate the domain. Shape the experience in the child.

Create a domain key