You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a web developer I want to access local hardware capabilities in client-side JavaScript, so that my web app can make full use of a user's device.
In addition to communicating with a connected device over a remote connection, what if the Web Thing Protocol could also be used by web pages to safely communicate with local hardware capabilities from JavaScript?
Example hardware capabilities:
Audio volume
Light sensor
Screen brightness
This could also offer an alternative to the proposed WebUSB, WebBluetooth, WebMIDI, WebNFC, WebSerial and WebGPIO client-side JavaScript APIs which all have similar security issues. Rather than prompting users for full access to a trusted low-level data bus using a client-side JavaScript API, WoT Thing Descriptions could be used to provide a higher level description of hardware capabilities which are easier for users to understand. Web pages could then request access to those capabilities and communicate with devices via the Web Thing Protocol, using the existing fetch and WebSocket JavaScript APIs.
Local WoT services could be discovered using DNS-SD, well-known localhost URIs or even DID documents.
Example devices:
MIDI keyboard
Bluetooth robot
Raspberry Pi HAT
USB nerf gun
The tricky part is the security model. How to authorise access to local web resources using something equivalent to OAuth. Capyloon have been experimenting with a decentralised approach to something like this using DID & UCAN. A less sophisticated solution might be to simply give those local services a FQDN using a secure tunnelling service and use OAuth2 and TLS. That might sound scary but could actually be safer than exposing low level data buses to arbitrary web pages behind an opaque permission prompt.
The text was updated successfully, but these errors were encountered:
Hello,
it's an interesting use case.
As you might now, we use WoT in Eclipse LMOS to abstract AI Agents, but also Tools.
Anthropic's Claude 3.5 Sonnet model is capable of interacting with tools that can manipulate a computer desktop environment.
At the same time they are proposing a Model Context Protocol (MCP), which is quite similar to WoT, since they are trying to abstract access to different kind of Things, such as Tools.
Google is working on Project Mariner, and AI Agent based on Gemini 2 that moves the cursor on your screen, clicks buttons, and fills out forms, allowing it to use and navigate websites much like a human would.
I think Google is even working on a new Browser for AI Agents. The IT world is moving fast right now.
I started a discussion with Anthropic about WoT.
But WoT can quickly be out of the race if the W3C does not take a position and bring WoT into play for an open, standardized WWW.
As a web developer I want to access local hardware capabilities in client-side JavaScript, so that my web app can make full use of a user's device.
In addition to communicating with a connected device over a remote connection, what if the Web Thing Protocol could also be used by web pages to safely communicate with local hardware capabilities from JavaScript?
Example hardware capabilities:
This could also offer an alternative to the proposed WebUSB, WebBluetooth, WebMIDI, WebNFC, WebSerial and WebGPIO client-side JavaScript APIs which all have similar security issues. Rather than prompting users for full access to a trusted low-level data bus using a client-side JavaScript API, WoT Thing Descriptions could be used to provide a higher level description of hardware capabilities which are easier for users to understand. Web pages could then request access to those capabilities and communicate with devices via the Web Thing Protocol, using the existing fetch and WebSocket JavaScript APIs.
Local WoT services could be discovered using DNS-SD, well-known localhost URIs or even DID documents.
Example devices:
The tricky part is the security model. How to authorise access to local web resources using something equivalent to OAuth. Capyloon have been experimenting with a decentralised approach to something like this using DID & UCAN. A less sophisticated solution might be to simply give those local services a FQDN using a secure tunnelling service and use OAuth2 and TLS. That might sound scary but could actually be safer than exposing low level data buses to arbitrary web pages behind an opaque permission prompt.
The text was updated successfully, but these errors were encountered: