-
Notifications
You must be signed in to change notification settings - Fork 7
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Link to the submitted request
- Loading branch information
Showing
1 changed file
with
2 additions
and
54 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,55 +1,3 @@ | ||
| ## Review Request | ||
| ## TAG early design review | ||
|
|
||
| I'm requesting a TAG review of the Local Peer-to-Peer API. | ||
|
|
||
| - Explainer¹ (minimally containing user needs and example code): [explainer](https://github.com/WICG/local-peer-to-peer/blob/main/EXPLAINER.md) | ||
| - User research: see [use cases](https://github.com/WICG/local-peer-to-peer/blob/main/EXPLAINER.md#use-cases) and [references](https://github.com/WICG/local-peer-to-peer/blob/main/EXPLAINER.md#references) with supporting user discussion and open-source projects | ||
| - Security and Privacy self-review²: [self-review](https://github.com/WICG/local-peer-to-peer/blob/main/security-privacy-questionnaire.md) | ||
| - GitHub repo (if you prefer feedback filed there): [WICG/local-peer-to-peer](https://github.com/WICG/local-peer-to-peer) | ||
| - Primary contacts (and their relationship to the specification): | ||
|
|
||
| - Anssi Kostiainen (@anssiko), [Intel Corporation](https://www.intel.com/) | ||
| - Belem Zhang (@ibelem), [Intel Corporation](https://www.intel.com/) | ||
| - Michiel De Backker (@backkem), [Twintag](https://twintag.com/) | ||
| - Wei Wang (@wangw-1991), [Intel Corporation](https://www.intel.com/) | ||
|
|
||
| - Organization/project driving the design: Intel, individual contributors | ||
| - External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): | ||
|
|
||
| Further details: | ||
|
|
||
| - [x] I have reviewed the TAG's [Web Platform Design Principles](https://www.w3.org/TR/design-principles/) | ||
| - The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG | ||
| - The group where standardization of this work is intended to be done ("unknown" if not known): currently unknown, possibly Second Screen WG due to the Open Screen Protocol foundations | ||
| - Existing major pieces of multi-stakeholder review or discussion of this design: https://github.com/WICG/proposals/issues/103 received encouraging feedback from multiple stakeholders and motivated this further work | ||
| - Major unresolved issues with or opposition to this design: no opposition per se, major unresolved issues noted as ℹ️ open points below | ||
| - This work is being funded by: Intel | ||
|
|
||
| You should also know that... | ||
|
|
||
| **The following design considerations would especially welcome TAG's feedback:** | ||
|
|
||
| - The Local Peer-to-Peer API aims to give browsers the means to communicate directly, without the aid of a server in the middle. It is designed to enable this communication within the confines of a [local communication medium](https://wicg.github.io/local-peer-to-peer/#local-communication-medium), a purposefully broad term defined for the purpose of this proposal. | ||
| - ℹ️ We are seeking feedback on the local communication terminology and level of abstraction this specification establishes. Is this level of abstraction desirable? [Early feedback](https://github.com/WICG/proposals/issues/103#issuecomment-1680472714) suggests web developers prefer to work with an API that abstracts out details of the underlying communication technologies. | ||
|
|
||
| - For improved developer ergonomics, APIs are provides for both [simple message exchange](https://github.com/WICG/local-peer-to-peer/blob/main/EXPLAINER.md#simple-message-exchange) and [advanced data exchange](https://github.com/WICG/local-peer-to-peer/blob/main/EXPLAINER.md#advanced-data-exchange) use cases. Also [shorthand APIs](https://github.com/WICG/local-peer-to-peer/blob/main/EXPLAINER.md#shorthand-apis) are under consideration and will be develop further subject to feedback. | ||
| - ℹ️ We would be in favor of a unification effort that aligns the DataChannel and WebTransport APIs across all transports (such as LP2P, WebRTC and HTTP/3). | ||
| - ℹ️ DataChannel vs WebTransport: should we keep both? [Tracking issue](https://github.com/WICG/local-peer-to-peer/issues/29) | ||
| - ℹ️ Adding the appropriate teardown/shutdown logic & events is pending. This will be addressed by studying precedent set by specs such as [WebRTC](https://www.w3.org/TR/webrtc/) and [WebTransport](https://www.w3.org/TR/webtransport/). | ||
|
|
||
| - [Local HTTPS](https://github.com/WICG/local-peer-to-peer/blob/main/EXPLAINER.md#local-https) is proposed to improve local use of HTTPS. This feature is illustrated and discussed in https://github.com/WICG/local-peer-to-peer/issues/34 and has real-world demand from e.g. an established media player software vendor https://github.com/WICG/local-peer-to-peer/issues/39 | ||
| - ℹ️ There is a question if a stricter CORS variant is warranted for local HTTPS sites [Tracking issue](https://github.com/WICG/local-peer-to-peer/issues/34) | ||
|
|
||
| - This specification purposefully makes an effort to stay within established security concepts. It exposes less information, such as IP information, about the peers involved than WebRTC, see [Security and Privacy self-review](https://github.com/WICG/local-peer-to-peer/blob/main/security-privacy-questionnaire.md). | ||
| - ℹ️ Security and privacy have been a major focus when designing this API. We're eager to hear about any concerns in this area so it can be addressed appropriately. | ||
|
|
||
| **Implementation experiments** | ||
|
|
||
| To help inform the API design, we are conducting a series of experiments to evaluate the feasibility of the design: | ||
|
|
||
| - [go-lp2p](https://github.com/backkem/go-lp2p): an experimental API implementation in Go. | ||
| - There is a WIP implementation of the Open Screen Protocol in [Chromium](https://chromium.googlesource.com/openscreen/). It is being upgraded to using [QUICHE](https://github.com/google/quiche) QUIC implementation. We intent to build a POC on top in the future. | ||
|
|
||
| We'd prefer the TAG provide feedback as (please delete all but the desired option): | ||
|
|
||
| 🐛 open issues in our GitHub repo for **each point of feedback** | ||
| Can be found from https://github.com/w3ctag/design-reviews/issues/932 |