You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- Add link to "Use Cases" in EXPLAINER.md
- Adjust the order of paragraphs to make them unified
- Remove "Examples" chapter temporarily: there are two examples, one is moved
to the corresponding chapter, the other one was removed due to duplication.
Maybe we can add the actual use cases based on this API in the future.
- Fix some errors.
@@ -26,7 +26,7 @@ The Local Peer-to-Peer API aims to give browsers the means to communicate direct
26
26
27
27
Many modern Web security measures rely on the presence of naming, signaling and certificate authorities. Local use-cases where these authorities are not readily available have started lagging behind in user experience or are not supported altogether. The Local Peer-to-Peer API aims to bring back first-class support for local communication use-cases while working within the same strict user-friendliness, security and privacy requirements.
28
28
29
-
Examples of potential uses of this API include: Collaboration tools that work during an internet outage or emergency situations, connecting to your NAS, your home security system, your robotic assistant doing the dishes or your GPU farm in the basement that's running your personalized virtual assistant.
29
+
Examples of potential uses of this API include: Collaboration tools that work during an internet outage or emergency situations, connecting to your NAS, your home security system, your robotic assistant doing the dishes or your GPU farm in the basement that's running your personalized virtual assistant. See also [Use Cases](https://github.com/WICG/local-peer-to-peer/blob/main/EXPLAINER.md#use-cases).
30
30
31
31
This specification aims to strike a balance between creating a powerful new building block for developers and providing a seamless, secure and privacy preserving experience for browser users. As an example: while the API doesn't provide raw socket access, it does aim to give developers the flexibility to innovate on top by providing a persistent, two-way communication channel with little overhead.
32
32
@@ -222,11 +222,11 @@ The capabilities of the Local WebTransport session are defined in [[!webtranspor
222
222
223
223
Note: The WebTransport-over-QUIC protocol is yet to be defined. Potentially considering earlier work such as [draft-vvv-webtransport-quic](https://datatracker.ietf.org/doc/html/draft-vvv-webtransport-quic-02).
224
224
225
+
<section algorithm="LP2PReceiver">
226
+
225
227
LP2PReceiver Interface {#lp2p-receiver}
226
228
================================================
227
229
228
-
<section algorithm="LP2PReceiver">
229
-
230
230
The <dfn interface>LP2PReceiver</dfn> interface allows advertising on the local network, enabling other peers to discover and connect.
@@ -439,11 +433,14 @@ const transport = new LP2PQuicTransport(conn);
439
433
await transport.ready;
440
434
</pre>
441
435
436
+
</section>
437
+
438
+
<section algorithm="LP2PDataChannel">
442
439
443
440
The LP2PDataChannel Interface {#lp2p-data-channel}
444
441
==========================================
445
442
446
-
The LP2PDataChannel interface represents a bi-directional data channel between two peers. An LP2PDataChannel is created via a [factory method](#lp2p-data-channel-extensions) on a LP2PConnection object.
443
+
The LP2PDataChannel interface represents a bi-directional data channel between two peers. An LP2PDataChannel is created via a [factory method](#lp2p-connection-data-channel-extensions) on a LP2PConnection object.
447
444
448
445
Note: The LP2PDataChannel interface is purposefully kept as close as possible to the [RTCDataChannel](https://www.w3.org/TR/webrtc/#rtcdatachannel) interface defined in [[!webrtc]]. The aim is to allow seamless transition of developers that are familiar with WebRTC as well as allowing libraries to easily work with both the [[!webrtc]] and LP2P API.
The following are the <a>event handlers</a> (and their corresponding <a>event handler event types</a>) that must be supported, as <a>event handler IDL attributes</a>, by all objects implementing the [[#lp2p-connection|LP2PConnection]] interface:
522
+
The following are the <a>event handlers</a> (and their corresponding <a>event handler event types</a>) that must be supported, as <a>event handler IDL attributes</a>, by all objects implementing the [[#lp2p-data-channel|LP2PDataChannel]] interface:
527
523
528
524
<table class="data">
529
525
<thead>
@@ -555,7 +551,7 @@ The following are the <a>event handlers</a> (and their corresponding <a>event ha
The following are the <a>event handlers</a> (and their corresponding <a>event handler event types</a>) that must be supported, as <a>event handler IDL attributes</a>, by all objects implementing the {{LP2PConnection}} interface:
@@ -626,6 +622,57 @@ The following are the <a>event handlers</a> (and their corresponding <a>event ha
Issue: In general, when defining a new interface that inherits from Event please always ask feedback from the WHATWG or the W3C WebApps WG community. See [defining event interfaces](https://dom.spec.whatwg.org/#defining-event-interfaces).
Issue: In general, when defining a new interface that inherits from Event please always ask feedback from the WHATWG or the W3C WebApps WG community. See [defining event interfaces](https://dom.spec.whatwg.org/#defining-event-interfaces).
0 commit comments