Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use Case: Provide web pages with access to local hardware capabilities #18

Open
benfrancis opened this issue Aug 22, 2022 · 1 comment
Labels

Comments

@benfrancis
Copy link
Member

benfrancis commented Aug 22, 2022

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.

@RobWin
Copy link
Collaborator

RobWin commented Dec 17, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants