Spec intro #22
Spec intro #22
Conversation
index.bs
Outdated
|
|
||
| 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. | ||
|
|
||
| The API is aimed to be implemented on top of a streams-based protocol such as [[!RFC9000|QUIC]]. This specification details an implementation on top of the |
There was a problem hiding this comment.
With the proposal for OSP split into Messaging and Connection resolved, perhaps we can say a bit more on the reference stack. A proposal drawing from the related issue #321:
The API is aimed to be implemented on top of a streams-based transport protocol such as [[!RFC9000|QUIC]] reusing the [Open Screen Protocol](https://w3c.github.io/openscreenprotocol/) for rendezvous and authentication.
Feel free to tweak words further. We can bring the stack diagram here when the OSP split is real and its details worked out, I think it'd be helpful.
There was a problem hiding this comment.
I agree with the OSP centric approach. Part of my aim here was to not fully close the door on other transports such as Wifi Direct. These may come with their own 'native' auth mechanism. If this is deemed valuable, we can still rewrite this to more strongly put the OSP implementation forward. If we're fine closing the door on other transports more, we can make OSP the sole protocol focus. Let me know your thoughts.
There was a problem hiding this comment.
Just wanted to mention that I think leaving "doors open" is better, in part because it is my hope that the spec accommodates alternative (non-HTTP) transports like BT, NFC, etc.
There was a problem hiding this comment.
This is an important discussion, thanks for your comments. I think we're in agreement. Let me expand my thoughts below:
I feel we're on a similar journey as with the Presentation API and Remote Playback API. Initially those APIs were implemented on top of proprietary stacks such as Google Cast, Apple AirPlay. After wider community review we initiated work on the Open Screen Protocol to enable what we refer to in the LP2P explainer as "an open standards-based implementation path". The OSP explainer is still good background reading with an eye on this new API. Now that we kicked off this new API we already had OSP fleshed out pretty nicely for us, so we want to make good use of it.
As a learning from the past experience I think we want to define an open standards-based horizontal stack where complementary innovation can happen on all the layers. That is OSP. I believe we agree on this goal. The opposite would be a proprietary vertical stack that allows only the owner of the vertical to innovate. This naturally inhibits interoperability, introduces silos. On some platforms a vertical stack may be the only way to implement this API and we want to allow that if technically feasible. There's things in between these two extremes.
I think we don't want to artificially close doors from alternative viable implementation paths such as Wi-Fi Direct. The implementation could pick the best backend for the job if multiple are available. The LP2P API as drafted is a high-level enough abstraction to be able to accommodate for that. As an example, the Presentation API spec does not take a dependency on the OSP spec. It is the OSP spec that defines the Presentation Protocol that maps to the API spec and its operations. This allows a standards-compliant Presentation API implementation on top of a non-OSP stack.
That's too many words, but I hope it makes some sense :) Maybe we could expand the intro to clarify this aspect by saying:
"The API is expected to be implementable on top of also other transports when technically feasible."
If we think it would help to enumerate some example transports to make this more concrete, that is fine too.
There was a problem hiding this comment.
Great, thanks for the guidance @anssiko. I've reworded this to bring OSP forward. I still kept the original structure of the intro by introducing the goal/motivation first and keeping the protocol implementation at the end. I refrained from listing alternative transport options for now.
|
@backkem, please check that your GH profile is linked with your W3C Account (to link it, go to https://www.w3.org/users/myprofile > Connected Accounts). This should turn the ipr check green. |
|
The checks are now green after some under the hood infrastructure fixes. FTR, not related to Michiel's account. I'll merge this PR to check the workflow still works with the current repo config. Further contributions to this section and other parts of the spec welcome via issues and PRs. |
This is a first stab at an introduction for the spec. I tried to keep it concise and to incorporate the feedback from #19 and #20.
Naturally, this may be over-fitted to my viewpoint so feedback is important.
cc @akbertram @getify @anssiko @ibelem @backkem @wangw-1991
To avoid duplicate work, I suggest to leave the explainer document as-is for now and re-align it with the specification is a bit more mature. The PR depends on #21. I will rebase when that is merged.
Preview | Diff