01 The model
How GID works
GID borrows HID's shape - a device that describes itself, interpreted by a host - and adds an address so input can name where it is going. Here is the model at a high level. The exact bytes are still being decided, on purpose.
02 The pieces
Four concepts
Descriptor
A machine-readable self-description: what the device is and what events it can emit. A host reads it once and knows how to interpret the device - no bespoke driver. This is the HID idea, carried forward.
Envelope
The framing around each event on the wire: it identifies the message, carries a version, and reserves room for fields that do not exist yet. Forward compatibility lives here.
Address
The new idea. Every event says which app it is for, so input can reach one app among several - not just whichever app the system has in front. This is the difference HID cannot express.
The target app
The app meant to receive the input - for example, one of several apps running on your glasses. Getting input to the right app is GID's whole reason to exist. What that app then draws on screen is someone else's job.
03 What it unlocks
Two things HID cannot do
Input reaches the right app
A GID device is not pretending to be a keyboard or mouse, so the phone's operating system does not capture its input the way it does with HID. Instead of being consumed by the system or pinned to whichever app is in front, each event carries an address and is delivered to the app it names.
The channel runs both ways
GID is not one-way. The app can send messages back to the device over the same link - switch it between modes, acknowledge a command, or drive feedback like haptics. Input and response share one self-describing channel, not a bespoke side channel per vendor.
04 Forward compatibility
The must-ignore rule
A standard is only as durable as its ability to grow without breaking what already shipped. GID's core rule is must-ignore: a conformant implementation silently skips fields and event types it does not understand. New input types and capabilities arrive through an extension mechanism, carried by the envelope, without invalidating devices already in the field.
That is why the early work is spent almost entirely on the decisions that cannot be taken back - the envelope, how it versions, the extension mechanism, and the addressing model. Get those right and almost everything else can be added later as a compatible extension.
05 Transport
BLE GATT first
The first transport binding is Bluetooth Low Energy GATT - the channel glasses controllers and companion apps already use in the field. A phone app acts as the relay between the controller and the app on your glasses. The envelope itself is transport-independent; BLE GATT is simply where the real hardware lives today, so it is where GID starts.
The full reference - descriptors, the envelope layout, the BLE binding, and a conformance definition - will live in the specification as those decisions lock.