-
Notifications
You must be signed in to change notification settings - Fork 26
Description
This is yet another thing that should be on our radar, as could impacr LAN and Web Browser connectivity story.
Summary
WICG Proposal's initial draft states utility relevant to IPFS in LAN contexts:
The Local Devices Protocol connects browsers to devices on the Local Area Network. Typically, these are devices such as NAS servers, Internet-connected TVs and IoT devices such as IP cameras, doorbells or thermostats.
This entire specification assumes operation in an air-gapped Local Area Network. There can be no reliance on cloud or other remote servers for core functionality. The browser and devices should communicate directly and only make use of readily available network protocols.
This proposal is highly similar to that of the Open Screen Protocol. This specification therefore often refers to it.
Or shorter pitch, highly aligned with IPFS/libp2p goals:
One of our design goals is to be offline-first with zero reliance on central infrastructure, including DNS or CAs. To that end we use self-signed certificates that are exchanged in the ‘pairing’ step, just like Bluetooth or Chromecast.
Good primer: Local.Devices.-.Building.Blocks.for.the.Local.Web.pdf
Highlights for IPFS
Some pieces that could be useful in IPFS contexts.
Note: below is very high level and TBD, this section is only signaling things we should look at when investigating this proposal in depth in the furture:
- mDNS for LAN discovery (we already have libp2p/mdns specs, but what this proposal brings is pairing UX in browser context)
- Authentication flow for marking self-signed TLS devices as Trusted
- Higher level protocols like HTTPS could then talk to them (by including Trusted devices in Secure Context).
- This could allow HTTPS websites to opportunistically fetching blocks and CARs from IPFS nodes in LAN (without "mixed-content" warnings)
- Higher level protocols like HTTPS could then talk to them (by including Trusted devices in Secure Context).
- "Virtual Local Devices API" may provide abstraction for having a single IPFS node across tabs and browsers (prior discussions: The Future of "accessing API of remote IPFS node" #137 and Node reuse and resource sharing on the web #158).
References
- Discussion thread at discourse.wicg.io
- Second Screen WG/CG - 2021 Q1 virtual meeting lightning talk: Local.Devices.-.Building.Blocks.for.the.Local.Web.pdf
- Open Screen Protocol
- Local Devices API repo: https://github.com/backkem/local-devices-api/issues