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

WICG Proposal - Local Devices API (LAN Services) #195

Open
lidel opened this issue Aug 10, 2022 · 1 comment
Open

WICG Proposal - Local Devices API (LAN Services) #195

lidel opened this issue Aug 10, 2022 · 1 comment
Labels
need/analysis Needs further analysis before proceeding need/triage Needs initial labeling and prioritization

Comments

@lidel
Copy link
Member

lidel commented Aug 10, 2022

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)
  • "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

@lidel lidel added need/analysis Needs further analysis before proceeding need/triage Needs initial labeling and prioritization labels Aug 10, 2022
@lidel lidel changed the title WICG Proposal - Local Devices Protocol WICG Proposal - Local Devices API (LAN Services) Aug 10, 2022
@galargh galargh moved this to To do in IPFS-GUI (PL EngRes) Sep 22, 2022
@backkem
Copy link

backkem commented Mar 26, 2024

The Local Peer-to-Peer API is the successor to the Local Devices API. It uses the same technical approach but has a more fleshed out draft spec. I made an experimental implementation at backkem/go-lp2p to help validate the design.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
need/analysis Needs further analysis before proceeding need/triage Needs initial labeling and prioritization
Projects
None yet
Development

No branches or pull requests

2 participants