-
Notifications
You must be signed in to change notification settings - Fork 7
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
TAG review prep #40
TAG review prep #40
Conversation
@ibelem can you check the overall flow of the updated explainer so we get more eyes on it? No need to dig deep into security-privacy-questionnaire.md at this time. Please flag anything that jumps at you or is unclear in the explainer. No need to review all the minute details, more the overall story. You can refer to the explainer template to get an idea what the TAG is expecting. You've thought a lot about the UX around this proposal so your expert comments on that area are also much appreciated. This is a substantive update (thanks @backkem!) with suggested changes we believe will help the explainer be even more helpful resource for TAG reviewers. Thanks! |
Thanks @anssiko and thanks @backkem for the great and substantive revision of the explainer, much better categories for use cases, and a more structured flow! Since we initialized the explainer, one aspect I regret not unify more clearly in the explainer is the network environment for the Local Peer-to-Peer API, we use different wordings in different chapters. Providing an explicit unified LP2P network environment would have eliminated any potential confusion, even though the overall meaning can still be inferred from context. This does not affect the integrity of the entire explainer, it is just my rough thoughts. Explainer:
Spec:
|
EXPLAINER.md
Outdated
- Disconnect automatically after a period of inactivity (implementation-defined e.g. 10 minutes) with an extension opportunity with a user's consent | ||
- Authorization on a per-session basis: Colleagues, friends, family members or the user themselves can authorize the “content pull request” on the device that can allow pulls for one session (e.g. 10 minutes) | ||
- We are investigating whether this API should be restricted to PWA only | ||
While the Web Share API partially satisfies the requirement R2 set forth above, the Web Share API by its design defines a minimal API surface that is likely not amenable to extensions required to support additional use cases and requirements outlined in this explainer. Notably, the Web Share API is a "push-based" API where content is pushed from one device to another device while the Local Peer-to-Peer API is catering to both the "push-based" as well as "pull-based" use cases as illustrated by "drop files here and share" and "import file nearby" concepts respectively. From the UX perspective, The Local Peer-to-Peer API allows for a more seamless in-web app experience in use cases where a system-provided share facility would disrupt the user flow. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From the UX perspective, The Local Peer-to-Peer API
From the UX perspective, the Local Peer-to-Peer API
I ticketed out the LAN Terminology issue. I'll try to find some time (maybe next weekend) to pick that up. I agree it would be good to get that sorted before submitting for review. |
This PR is in preparation for an early TAG review. I altered the explainer to more directly answer the questions of the survey.