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

The web platform needs a service discovery mechanism #240

Closed
cynthia opened this issue Apr 7, 2018 · 16 comments
Closed

The web platform needs a service discovery mechanism #240

cynthia opened this issue Apr 7, 2018 · 16 comments
Assignees
Labels
Missing: venue Mode: breakout Work done during a time-limited breakout session Progress: propose closing we think it should be closed but are waiting on some feedback or consensus Review type: deep thoughts Topic: Architecture Architecture related topics Venue: TAG

Comments

@cynthia
Copy link
Member

cynthia commented Apr 7, 2018

While reviewing #237 in the Tokyo F2F, it came to our attention that the platform lacks a good mechanism for service discovery.

One of the ideas that came out of the discussion was to look into what the .well-known "bootstrapping" is attempting to solve, and prototype some of the ideas we had on top of DNS SRV records. (and possibly publish as a finding?)

@mamund
Copy link

mamund commented Apr 11, 2018

Over the last month or so I've been working on a PoC on "open discovery" for the Web:
http://www.open-disco.org/

Not sure if this is along the lines you were thinking and would be happy to share my code and other notes with anyone who might be interested.

@plinss
Copy link
Member

plinss commented Jul 26, 2018

@plinss to write up a blog post about service discovery, submit to w3c strategy funnel

@torgo
Copy link
Member

torgo commented Feb 5, 2019

@cynthia to confab with @plinss

@hadleybeeman
Copy link
Member

Discussed at Iceland f2f.

@cynthia is going to arrange a breakout at TPAC with @plinss and interested parties, to flesh out what devices need to find each other. Probably with the media use case first; finding server; finding set top/desktop.

(@chrisn? @anssiko? Are you interested? Anyone else?)

@kenchris
Copy link

@larsgk might be interested

@mamund
Copy link

mamund commented May 22, 2019

I'd be interested in this. been working on a service-level discovery pattern for open web here: http://www.open-disco.org/.

@anssiko
Copy link

anssiko commented May 22, 2019

Second Screen CG has been working on the Open Screen Protocol https://webscreens.github.io/openscreenprotocol/ for devices that can render web content like Internet-connected TVs, HDMI dongles. OSP-compliant devices use DNS-SD over mDNS to find each other, QUIC for transport and metadata discovery. The spec is now considered ”feature complete” CG draft and is being prepared for TAG review. We have F2F https://www.w3.org/wiki/Second_Screen/Meetings/May_2019_F2F tomorrow, so I’ll put this issue on the F2F agenda.

@mfoltzgoogle would be a key contributor to this proposed TPAC breakout session.

@chrisn
Copy link

chrisn commented May 23, 2019

Thanks @hadleybeeman, I'm certainly interested.

@larsgk
Copy link

larsgk commented May 23, 2019

Thanks @kenchris - VERY relevant, thanks!

@cynthia
Copy link
Member Author

cynthia commented May 23, 2019

Just to be clear, the part that this touches on is the hardcoded part in section 3 in the OSP spec. I’m not particularly thrilled about exposing mDNS (with all it’s quirks) over the web platform, but it is indeed a viable option since it has extremely wide adoption. (We previously attempted this in the past with NFD spec, but I don’t consider that a success.) What we would like to see come out of the discussion is the following:

  1. A common API interface/pattern for designing service discover-like features (e.g. local network and bluetooth might be examples where we can have a similar API pattern), sort of like what we did with streams
  2. A mechanism for exposing/discovering network services (e.g. query default dns resolver, mDNS, etc.)

Do note that this is not a place where we are gathering proposals, it’s more of a architectural concern issue where we want to not do N inconsistent API patterns, and end up with a pile of regret later.

We mentioned media because it feels like the most immediately use case which can benefit from this - as a immediate example, Plex does a lot of interesting (en_UK interesting) things to work around this not being available; so there is a clear need.

Should we setup a separate call to discuss if this is worth a plenary breakout during TPAC later this year?

@ylafon
Copy link
Member

ylafon commented May 28, 2020

On top of this, discovery mechanism should ideally have measures to avoid doing "service scanning", like by poking too much in well-known URIs, something equivalent to port scanning.

@torgo
Copy link
Member

torgo commented Sep 7, 2021

Discussed today possible outcomes of this issue since the TAG likely won't itself take up work in this area. We discussed raising a process issue, raising it to the team, other options...

@cynthia
Copy link
Member Author

cynthia commented Sep 7, 2021

Let me try to find out what happened with this https://developer.chrome.com/docs/extensions/reference/mdns/ - might be a start.

(on non-TAG capacity)

@hadleybeeman
Copy link
Member

We discussed this at our W3CTAG Moon base alpha face-to-face.

We agreed that this work should be incubated in a community group. @plinss has taken on that task. I will set this this to proposed closing, and we intend to close it when the CG is spun up and the discussion can move there.

@hadleybeeman hadleybeeman added Progress: propose closing we think it should be closed but are waiting on some feedback or consensus and removed Progress: stalled labels Feb 8, 2023
@plinss
Copy link
Member

plinss commented Feb 8, 2023

CG proposed looking for supporters...

@plinss
Copy link
Member

plinss commented Apr 18, 2023

CG created

@plinss plinss closed this as completed Apr 18, 2023
@rhiaro rhiaro added Mode: breakout Work done during a time-limited breakout session and removed Big chunk of work labels May 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Missing: venue Mode: breakout Work done during a time-limited breakout session Progress: propose closing we think it should be closed but are waiting on some feedback or consensus Review type: deep thoughts Topic: Architecture Architecture related topics Venue: TAG
Projects
None yet
Development

No branches or pull requests