Meeting minutes
Charter Call for Review Result
angel: hello everybody!
angel: there are still a few open issues
<angel> https://github.com/w3c/miniapp/issues
<xfq> https://github.com/w3c/miniapp/issues?q=is%3Aissue+is%3Aopen+label%3Acharter
angel: issue labeled as charter
https://github.com/w3c/miniapp/issues/84
angel: I think we resolved not to mentioned EPub3 in the Coordination section
… xfq, please close this issue
https://github.com/w3c/miniapp/issues/79
Previous discussions: https://www.w3.org/2020/06/18-miniapp-minutes.html#t02
angel: it has been pointed out that the scope is too open-ended and is similar to the scope in the old SysApps WG
… we discuss a little bit last time
… we have some discussions going on
… shall we modify our charter for this request?
… Sam reopened this issue and reminded our the potential Sec and Privacy issues
xiaoqian: we should identify what kind of components/APIs we would like to standardize
fuqiao: avoid making the charter scope open ended, which will cause a lot of security/privacy/patent concern
… that will block many companies to join the group
… suggests to remove "API" from the scope until we can specify what APIs to produce in future
… to incubate new APIs in CG and then bring them to WG with rechartering
Yongjing: my understanding is that the WG won't develop APIs that overlap with other existing groups
… we can mention that in the charter
Qing_An: we can mention Lifecycle APIs
Fuqiao: it's included in the 1st item of Scope
… issue is about the 2nd item
… which makes this charter open ended
Han: we can set up restrictions wrt "APIs"
<xiaoqian> han: I suggested we followed the comments and set limits to the APIs and Elements, to make sure Sec and Privacy doesn't hurt
Fuqiao: even if we have a minimum bar for privacy and security for Components and APIs
… there're still possibilities of developing a lot APIs, causing patent implications
<xiaoqian> han: one of our concern is the output of the co-ordination? will this add deliverable to the group?
Angel: I understand Han's concern
… do we have clear targets of APIs we want to develop?
… if we're not sure, we can move the item 2 "Components, APIs" to CG for incubation
… keep basic architecture in scope
xfq: I agree
Qing_An: I agree
<xiaoqian> Han: maybe we can be more specific about the APIs, those APIs there is common features among miniapps, must be in all implementations
Yongjing: we could use the last sentence in the comment: this group do not intent to overlap the current APIs of the other groups
… I don't want to miss the point that we have intention to work on components and APIs
angel: we need to be cautious about the last sentence, because other groups are already working on packaging, manifest, and lifecycle
… I like your point, but we need to paraphrase this
… time limited for today, we need at least 20 minutes for the next topic, so we should be quick
[debugging audio issues]
Yongjing: My understanding of the word "overlap" may be different from angel
… in my mind, "overlap" means exactly the same thing
… but miniapp minifest/packaging/lifecycle and existing work in W3C are similar but different
Angel: proper wording is important
… let's reword the second part of scope section
… do not repeat existing work in W3C WGs, and only works on the "core" APIs
… I will try to paraphrase this on GitHub and welcome inputs
https://github.com/w3c/miniapp/issues/77
xfq: I have a PR waiting for Sam's reply
Fuqiao: I will ping Sam
https://github.com/w3c/miniapp/issues/75
Fuqiao: Yongjing has updated the draft charter
angel: please ping Sam to get his feedback
https://github.com/w3c/miniapp/issues/60
angel: could we develop more clear testing policy? We still need to explore
… keep this issue open
xiaoqian: I agree with angel
Next Steps: FAQ
Angel: we should review our FAQ
… questions and answers
… I see most of them already have answers
Question 1
Question: Is MiniApp a part of Web Platform? What is the relationship between MiniApp and Web Platform?
… any volunteers to answer this question?
xiaoqian: if nobody has the time to answer, fuqiao and I can handle this one
Angel: before fuqiao and you write the answer, a question for miniapp vendors, is the miniapp a part of web platform?
Qing_An: what is the definition of the web platform?
… hard for us to answer
Angel: I would like to say it is not the web platform
… it's "applications", not the "pure web" W3C has been working on
… this is just personal opinion
Han: my own opinion is similar to angel's
… it is different from web browser, containing features from the native platform too
Angel: miniapp introduces new possibilities for the web
… xiaoqian and fuqiao, please help answer the first question
xiaoqian: sure
Question 2
Question: If MiniApp uses certain parts of Web technologies, how come it runs without a browser engine?
<xfq> https://github.com/w3c/miniapp/issues/109#issuecomment-654904899
Tenyuan_Zhang: it may work, we think it can build miniapp runtime
Action: Fuqiao and Xiaoqian to draft answer for Q1
Action: Fuqiao to combine Yongjing's answer to Q2
Fuqiao: feedback from Yongjing, every miniapp implementation has their own hosting platform, it could be native app or OS, but not a web browser
… the hosting platform may or may not use WebView
… does not depend on a web browser
… I will draft an initial Markdown document for the FAQ
Question 3
Question: How is MiniApp Manifest different from WebApp Manifest? Could MiniApp Manifest become a unique case for WebApp Manifest? Could MiniApp Manifest be merged into the WebApp Manifest?
angel: I think Yongjing has answers to this question
Yongjing: I could take this action, our explainer has answered this question, I could summarize it here to answer question
xiaoqian: I talked to the editors of web app manifest
… they have a 4-hour teleconference every week
… everyone in the CG can join their meeting
Yongjing: lots of task should be done, we could talk about this offline
… I do not to intend to merge the two manifest specs, but willing to align the two specs
Question 4
Question: Why there is need to create a new URI Scheme specification? How to use the new URI Scheme specification to handle origin? How to handle SecureContext without origin? How to handle CORS?
https://github.com/w3c/miniapp/issues/109#issuecomment-655338168
angel: answer has landed, any more comments?
Dan_Zhou: have some different options on CORS
Yongjing: I don't know if my understanding of the same-origin policy is correct
… but I think to apply the same-origin policy, there needs to be a server
… but a miniapp is just an application, which may or may not have a web server as backend
… a server is not mandatory
… a miniapp does not require any network-related stuff
… a local-only miniapp is rare, but "origin" should not be required
Dan_Zhou: need more explanation on this question
Yongjing: not sure what SecureContext means here
xfq: secure context is basically HTTPS, for preventing MITM attackers
Yongjing: miniapp could be delivered in multiple ways, http is not only way to deliver the package
… http should not be the basic assumption
Dan_Zhou: do we have plan to create a new protocol?
Yongjing: my point is that http should not be the only protocol
… that's why we need URI scheme
xiaoqian: how about we assign this to Dan_Zhou to let her talk with the Quick Apps folks about protocols?
Yongjing: we should be clear about the use cases of the URI scheme, such as share use case
… I have some assumption but not sure they're true
Dan_Zhou: we could talk about this offline
Question 5
Question: Is it possible to harmonize Page Lifecycle, PWA Lifecycle and MiniApp Lifecycle specifications? If so, how??
angel: answered by Qing_An
https://github.com/w3c/miniapp/issues/109#issuecomment-654212767
angel: any additions to Qing_An's answer?
[silence]
Question 6
Question: Is it possible for MiniApp packaging to leverage the existing discussions such as signed exchanges and Web Packaging?
https://github.com/w3c/miniapp/issues/109#issuecomment-654904899
yongjing: already there in explainer
https://github.com/w3c/miniapp/blob/gh-pages/specs/packaging/docs/explainer.md
Question 7
Question: What is the implementation expectations of MiniApp specifications in the globe? Are the implementations only expected from Chinese MiniApp vendors?
Angel: we don't have an answer for this yet
… currently most miniapp vendors are Chinese companies
… it would be great if some international companies would like to implement some of our specs
Qing_An: Line also has miniapps, is Line a W3C member?
fuqiao: yes
Angel: this means miniapp is no longer a China-only thing
… looks like there are possibilities for international vendors to implement it
… I'll take the action to write an answer for this question then
Question 8
Question: Does MiniApp have its own security model?
https://github.com/w3c/miniapp/issues/109#issuecomment-654904899
yongjing: answered this question in an email
… not sure what "security model" means, but I could add some security model for packaging into the issue
Fuqiao: you could reply on GitHub issue, I will merge it to draft document
MiniApp Virtual Meeting
Xueyuan: please view the draft meeting page, check the proposed time and topics, we will reach to potential speakers to pre-record talks and then have live session for the mtg
angel: we can discuss that in emails and phone calls
Han: I want to check with our team about the timeline and then get back within a week
AOB
Angel: next meeting 6 August, same time
… thank you all!
[adjourned]