Meeting minutes
Welcome and Objectives
<wseltzer> Introductory Slides
wseltzer: please join IRC for our speakers' queue
… thank you everyone to make this meeting possible
… you can find the agenda of this meeting on the website
… hope you have reviewed the material beforehand
… I'm Wendy Seltzer, W3C Strategy Lead
… in the Strategy team we are looking at new technologies and their potential to fit into the Web
… as you know in W3C we work on consensus by standards
… it's not about finding the perfect
… in the case of miniapps
… can we make it something globally and work for the whole platform
… please join the discussion and contribute your ideas
… share your understanding
… let it be an opportunity for dialogs to reach concensus
… hope by the end of tomorrow we can have concrete plans to move to the next step
… in the first session Yinli Chen will lead us in the MiniApp Overview discussion
MiniApp Overview
Yinli: this is Yinli from Xiaomi, I'm going to talk in Chinese
… in the pre-recording video, I shared with you what's MiniApp, a few typical use cases, how MiniApp works and how to develop a MiniApp
Wendy: thank you for preparing the material, any questions?
xfq: I noticed that you mentioned in the video MiniApp can communicate with other apps
… what's the plan on this vision?
Yinli: I'm going to answer the question from the prospective of QuickApp
… in QuickApp there is a high-level API which maintains a communication channel
… package can be sent through this channel
<Zakim> dom, you wanted to ask mini-apps market convergence, mini-app outside of China, browser <-> mini app interactions
dom: in turns of the overview of MiniApp
… want to get some clarification where do miniapp fit into the overall platform
… the CG is looking to convergence of the MiniApp platform in China
… how many users will be covered by these platforms?
… how broadly is it used outside China?
… how it interact within and without the Web Platform?
Angel: I would like to explain some of my own observations
... There are roughly 1 billion MiniApp users in China.
... And there is Line from Japan and some other similar applications rising in SEA.
... Recently MiniApp-ish applications start to appear in US market as well. All these shows great potential of MiniApp as a new kind of application.
dom: the third question is about how MiniApp interact with webpages?
... in the URI proposal, there seems to be an expectation you can follow a link and browse a webpage
Angel: as for MiniApp and web pages, as far as I know, there is no miniapp running in browser conext yet in China, but the vision is to get MiniApp ubiquitous, and that's why MiniApp community came to W3C to make standards for it
wendy: any other questions and comments?
... next will be the TAG Review session
TAG review
DanA: This is Daniel Appelquist, working for samsung
… co-chair of the W3C TAG
<xfq> TAG Review / Statement on MiniApp Specs
DanA: I'm wearing a T-shirt of MDN today... as we mentioned in our feedback document, the web is a ecosystem that doesn’t only contains browsers, or products of the W3C members, cross devices and cross OS-es
… MDN is also a popular devleoper platform in China, we want to make W3C welcoming as well. Working on MiniApp in W3C can get the most of venders and developers resources. We send a long document a few days ago.
I’ll introduce it a bit
… this document is in reference to 3 TAG review requests
… we really appreciated being asked to review
… and thanks for going through the TAG review process
… it's an honor to review early, so that we can provide feedback and influence the design. We want to play a positive role
… we really want to reach the goal of one web, when we are building new technology, we want it to be muti-browser, Multi-OS and device, to consistent context when difference groups of users are trying to access it from different device
<dom> Thematic Consistency
Dan: in TPAC 2019, we provide a few feedbacks, one of the feedbacks is to interoperate with the current web technology as much as possible
… we went into a few historical stories that it can be a mistake to create different technologies in parallel without communication
… especially when there is an existing work item in other working group
<xfq> https://w3ctag.github.io/design-principles/#extend-manifests
Dan: such as manifest, we would prefer to have one manifest instead of one for web apps and one for miniapp
to decrease the complexity
… we have similar feedback fo the URI
it would be a really good idea to developer a MiniApp without another MiniApp URI scheme, sangwhan is willing to help
… also the lifecycle as the one in Web App
… packaging, there is an existing set of work around web packaging
… please consider merge these tasks to one packaging proposal
… one of the principle we want to highlight is the Web Security Model
… security is important, when a user clicks a URI, they know where they are leading to and it’s safe. We want it make sure this principle can be apply to MiniApp as well. Happy to take questions
any other suggestions from sangwhan and Tess?
<dom> [there is a dedicated Usession on RI scheme scheduled for tomorrow fwiw]
sangwhan: we actually made this mistake in the past so we would like to help … we created a new URI scheme and it broke a lot of others
<dom> [said otherwise, a new uri scheme for browser content requires forking the security model to adapt to a different origin model]
Dan: it’s really good to hear that the goal is to introperate with the web and other platform
Ralph: W3C staff. Thanks Dan and Sangwhan for the comments.
… do you have any suggestions to hook in existing one
... I wonder in tomorrow's URI session, if you can give more details
... about the particular use case that the MiniApp describes of allowing the environment to know
... when they already have that code present locally to support the MiniApp
… do you have any suggestions to help the MiniApp designers know
... where to hook into one of the existing Scheme stacks
... such that the environment can know what they actually do a network fetch or not
... maybe you can get into that details in tomorrow sessions
... I see there are use cases
... the comments about using an existing URI Scheme and existing browser specs
<Yves> XML catalogs provides an answer that resolution can be local for http URLs
Ralph: I am not sure that combination has a clear response to the MiniApp design
Wendy: Thank you. Noting that tomorrow we will have the URI Scheme session
<Zakim> dom, you wanted to surface possible competing needs in mini app standardization vs mini app / web convergence
<dka_> Also to be clear: when I'm talking about security, TLS (https) is also a key element.
<sangwhan> Re: Ralph's question, we do have some concrete+potentially actionable feedback.
<Yves> and more recently webpackage address alternative URL resolution
Dom: heard the conversations in this space
... on one hand, we have this huge thriving web platform for global
... and we probably have 1 billion MiniApp users
... that ecosystem needs a standardization
... in addition to the needs to standardize this existing ecosystem
... there's also a strong desire to have that ecosystem converged/merged with another existing huge thriving ecosystem
... which is the web platform
... I think there's an expect of the convergence which is about timing and @1
... in the ways we approach, sometimes challenging questions
... we need to consider which one needs to be addressed in long term
... also the ones in shorter term towards the convergence
... understand which of the answers are coming up with
... we can't let the two huge environments diverge too much if we want to converge
... need to find redline that prevents this convergence and identify greenline to facilitate such convergence
Wendy: Thanks Dom. It's helpful in thinking about our priorities
... as groups thinking of the MiniApp and Web platform together
... and what is critical for interoperability of these solutions
... it's most important to find consensus standards
... we need to find solutions that the tech can work together
Angel: as MiniApp CG co-Chair, I'd like to thank TAG for reviewing the MiniApp proposals
... we appreciate the feedback
... the majority CG members think that MiniApp might not be a typical part of the open web platform
... but it does introduce the web tech into native apps
... it's one of the most successful hybrid applications in market
... that brings a lot potential
... MiniApp features one web is not by design
... MiniApp platforms are facing fragmentization as well
... that's why we need standards
... we see good potential of MiniApp
... if you look at the MiniApp one web
... that with multi browsers, OS, devices, etc.
... there's a way to find interoperability between MiniApp and user agents
... all the MiniApp proposals are from real market requirements
... and have reasonable potential to be increased and implemented by the main stream MiniApp vendors
... I like us to have discussions about feasible ways to move the work forward
Chunming: Chunming from W3C. Thanks TAG for review MiniApp proposals
... MiniApp is supplement to the whole Web technologies
... it's important to consider the intersection between these two
... MiniApp is developing rapidly
… the web today has changed a lot comparing with 30 years ago
... I want to encourage our discussion today to, on one hand
... consider the existing vendors' implementations on the MiniApp platform
... and from the perspective of finding the overlap between MiniApp and Web tech
... what will be the MiniApp vision in future
... discussion not limited to current MiniApp implementations today
... but also the long term
... we may have more solutions based on communication between TAG and MiniApp CG
Wendy: 5 mins break
<dka_> +1 to Dom's comments by the way - we don't have to solve all of these issues immediately. But we do need to get some things on the right track. Manifest file could be the best place to start in my view.
Break
MiniApp Manifest & Packaging
Wendy: Zhang yongjing will give us the manifest and packaging introduction
yongjing: this is Yongjing from Huawei
… I'd like to thanks W3C to give us the opportunity for miniapp standardization
… I'd like to briefly introduce miniapp package & manifest
… we have received feedback from the TAG
… will introduce the rationale and the uniqueness of miniapp comparing to existing technologies
… first of all, a miniapp package is a zip file
… big difference with traditional web package
<xfq_> MiniApp Package explainer
yongjing: more like a native app
<slightlyoff> I'm unclear on the difference between "web resources" and "resources needed to run the app"
<xfq_> MiniApp Manifest explainer
yongjing: inside the package
… manifest gives more metadata for the hosting platform to parse a miniapp package
… we noticed the feedback from the TAG about manifest, which makes a lot of sense
… we also did gap analysis, and define some unique requirements from miniapp
… like version control and permission control
… these are within the scope of miniapp
… these are urgent questions to answer
… and we need do extension for Web platform or a separate specification, that will be a long term discussion
… we open to exchange ideas with WebApps WG
… my video have explained more detail about gaps
… that's all from my side
<Zakim> dom, you wanted to encourage sharing with webappmanifest (see usage of PWA in stores), comment on intersection with permissions policy
Dom: my perception is that it is a good opportunity to share with web app manifest
… will miniapp manifest be an extension of web app manifest? or only share some members?
… needs more conversations
… great first step
… in particular because web app manifest is not only used in web apps
… but has also been used in native app stores
<xfq_> Define a permission model?
Dom: very likely that a lot of coverage can happen on this one
… W3C has a lot of work on permissions
… we should understand the difference between the permission info in miniapp and W3C permissions policy
yongjing: one to add, current work on miniapp manifest and packaging are not mature enough
… I didn't mention permissions, we need more time on permission which Dom mentioned
… ongoing work
… people may identify more permission soon or later
<slightlyoff> there has also been discussion about enumerating permissions from the list Dom raised within Web App Manifests, and I'd personally be happy to see them added there as "high water mark" permissions
<plh>
PLH: there is renewed work on web app manifest
… a new spec has been developed, called Web App Manifest - Application Information
… microsoft store uses it
… web app manifest is a vocabulary
… mini app manifest can reuse these properties, instead of inventing new ones
… I made a pull request a few days ago, but do not merge for now
… because we should not use Web IDL
… but if you look into it, you can see how we can make the miniapp manifest based on web app manifest
<xfq_> https://github.com/w3c/miniapp/pull/119
<sangwhan> Re: PLH's comments about WebIDL in the manifest, +1 - manifest should be usable by non-browsers
yongjing: that's a good input
… especially you mentioned that JSON schema should be used instead of Web IDL
… it would encourage more collaboration
plh: Thank you
<slightlyoff> from Google's perspective, we'd like to see convergence of packaging and manifest formats
<slightlyoff> (in line with the TAG's recommendations)
Wendy: From W3C side, it is a very good early project to provide extension for existing manifest
… users of the manifest file can take advantage from this
… PLH work on integrating
<Yves> note that it goes both ways, requirements from mini-apps should be takken into account in the base spec (Manifest in that case)
yongjing: want more comments from package side
<dom> [I don't know if it matters, but I see a comparison with LPF, but not ePub OCF]
yongjing: the purpose of WPACK and miniapp packaging are different
… don't have a good solution to combine two packaging formats together, hope some inputs on this
fuqiao: you mentioned digital signature, more information on this?
<tidoust> [I note that I don't understand the "Web dependency" column in this comparison table. That seems to be more a "Origin-based" column, so back to the security question]
<slightlyoff> +1 to that, tidoust
yongjing: digital signature feature is under discussion
… takes a lot of time to design a secure and proven solution
<dom> [the piece about signing a ZIP package with Web content might be standardizable in abstraction of miniapps; sharing Web content as ZIP sounds like a useful thing (separately from WPACK)]
yongjing: similar to Android APK, that's something I have in mind
… feedback is welcome
… signature machnism is to protect the whole package, not just the files inside the package, different from some of the existing package technologies
… stronger than some existing package technologies
<sangwhan> I would like to note that addressing subresources in ZIP/DEFLATE can be very inefficient.
<slightlyoff> I should note that it's possible to add an overall signature to the `signatures` section of a web package: https://wicg.github.io/webpackage/draft-yasskin-wpack-bundled-exchanges.html#name-parsing-the-signatures-sect
fuqiao: saw styling mentioned in the packaging
… is styling the same as CSS in the browser? Or is there any divergence?
yongjing: haven't started to discuss this in CG yet
… will try to use CSS as much as possible
xfq: we can dicuss this in GitHub and/or CG calls
Alex: web packaging doesn't allow us to specify signature for the whole package
… it would be interesting
… can be a requirement
… of course a single manifest format would be useful
<Zakim> xiaoqian, you wanted to react to slightlyoff
<dka_> Unfortunately I am going to have to drop but I would like to +1 Alex's comments on web packaging.
<Yves> ZIP has the disadvantage to have the catalog at the end, removing the opportunity of early processing (ie: while not completely downloaded), but apparently it is not an issue right now
<sangwhan> Also not sure why the "format" (RFC7049) is inadequate for miniapps - it's a royalty free, open IETF standard that has multiple implementations for different languages/platforms
xiaoqian: question for Alex
… you mentioned there is a packaging proposal in WICG, is there any timeline?
<dka_> However it's good to hear about the momentum regarding the manifest file. I think this is a great first step.
Alex: thank you for the question
… the packaging format is designed in a layered way, in both IETF and W3C
… I could provide more detail in IRC on implementation status
zhoudan: want to answer previous question, not related to packaging & manifest
… the question is about how miniapp and web link to each other, it show in my slide 17
… from web app to miniapp: use href
… from miniapp to webapp: use WebView
… from miniapp to miniapp: use API
… if browsers implement miniapps
… I hope the three ways above will be possible
<slightlyoff> Web Bundles (multiple resources) are being developed in Chromium, with status tracked here: https://chromestatus.com/feature/5377722941440000
zhoudan: another question for Dan in TAG feedback, what is "Templated URL"?
<dom> URI Template (I assume)
<xfq_> https://tools.ietf.org/html/rfc6570
<plh> slide 17 in https://www.w3.org/2020/07/miniapp-virtual-meeting/slides/MiniApp-URI-Scheme.pdf
zhoudan: another question
… you mentioned you want more code demos, do you mean miniapp code or engine code?
Wendy: Unfortunately Dan has left the meeting
… you can ask him tomorrow
<xfq_> Discussion of the feasibility of using HTTPs as MiniApp URI scheme
<dom> https://www.w3.org/2020/07/miniapp-virtual-meeting/slides/MiniApp-URI-Scheme.pdf#page=17
<Yves> template URI was more in response of one aspect of the mini app url scheme that was using the version as a way to construct an http url, but it might not even be needed
<slightlyoff> Yongjing_Zhang: I can try to answer that
Yongjing: comments welcome for packaging
… some features in existing packaging formats are really irrelevant to miniapps
… don't know how to align them
Dom: I don't have an answer to Yongjing's question
… it's not clear that miniapp will be seen as a interoperability target by browsers
Alex: in Web app model
… use a URL to show content, and security also included in it
… allows distribution from different origin from the supplier
… web packaging allows us to use the web security model
Yongjing: that's the difference between with miniapp and web apps
… miniapp doesn't always assume the existence of an origin and HTTP exchanges
… we may need more discussion to see if it's possible to converge these two paradigms
Alex: I realized those may have huge different
Wendy: Thank you!
MiniApp Lifecycle
Wendy: next topic will be miniapp lifecycle
<xfq_> MiniApp Lifecycle
anqing: I will give a brief introduction here
<xfq_> explainer
anqing: MiniApp lifecycle is consist of two layers, one is page lifecycle and app lifecycle because MiniApp itself contains app layer and page layer
… in the TAG feedback MiniApp lifecycle will have some overlap with the WICG page lifecycle proposal
<slightlyoff> hrm, we already have a longstanding `onload` event
anqing: as I mentioned in slides, the WICG page lifecycle prposal is focusing in page layer, while we need to take into consideration of the app layer in the miniapp prposal. A few events haven't been covered by the page lifecycle proposal. The TAG also mentioned the PWA lifecycle, it'd be good to have a document or link to PWA lifecycle
<slightlyoff> PWAs use the page lifecycle + the serviceworker lifecycle
<slightlyoff> e.g.: https://developers.google.com/web/fundamentals/primers/service-workers/lifecycle
anqing: in W3C, we want to try to define a harmonised lifecycle api
<slightlyoff> you can think of the ServiceWorker lifecycle as the application installation and iteration phases, with the page lifecycle events (onload, visibility change events, hide/show events) as view-level events
<slightlyoff> (apologies, I need to drop off the call but will lurk here to answer questions)
Ralph: I may missed some points in slides, to what extend is a complete offline use case of the interest of the architect of the MiniApp lifecycle? would you envision that there are miniapps that users have installed but after they installed, they never talk to the internet?
anqing: from deployment prospective miniapp needs to be connected/online. Most of the features are provided by the cloud or the server. Off-line users get limited feature
Ralph: is it possible to develop a totally offline miniapp?
anqing: in theory yes, that's possible
<Yongjing_Zhang> regarding why RFC7049/CBOR is not used for miniapps, it's simply a choice of the ecosystem - all the current miniapp implementations are ZIP-based as far as I know. Since the main purpose of miniapp package is to archive files of the app. ZIP is straightforward while CBOR is not.
<Zakim> angel, you wanted to ask the rec plan of lifecycle in WICG
<slightlyoff> we picked something other than Zip for web packaging because of the architecture (and performance) issues around the Central Directory entry being located at the end of the (physical) file or stream
yongjing: internet connection doesn't necessarily mean it's connecting to a website, it can be any inapp services, that's something different we need to consider between the Web
<slightlyoff> this means we can't efficiently use Zip on web
angel: is there any Rec-track plan for lifecycle plan in WICG?
… is it worth the efforts to set up a group for a document covering both?
wendy: that will be a homework for us
<xfq_> https://github.com/WICG/page-lifecycle
xiaoqian: when we last reviewed, suggestion was to merge back to HTML
<xfq_> Modifications to the HTML Standard
chunming: after the loading and installation, what's difference on lifecycle between a PWA and a miniapp?
anqing: if you only look at pre download process, it doesn't have so much differece
… when to goes to first page rendering, page layout
<Zakim> MikeSmith, you wanted to comment about costs related to HTML spec integration
anqing: but miniapp will use cache resource to keep an instance and so user can open it quickly next time
PLH: it’s be good to understand the what’s the problem working with the whatwg community, encourage people to raise issues directly in WHATWG repos, in our cooperation with WHATWG
Mike: encourage everybody to rais issue in the WHATWG repo, of course there is cost for communication. Compare the long term cost not working with the html spec and the short term pain to engage with editors, it's worthy. The HTML editors do challenge a lot of the assumptions. it will be helpful show up a clear description of what problem you are going to solve than a solution in hand. The long term plan of the page lifecycle is to intergrated with HTML, so they are doing monkey packing of the SW spec and HTML. That's not something you should do for long. Please avoid monkey packing for long and please engage with the editors if you are working on the core APIs at this level. I'm super happy to help at any level I can.
Theresa: Theresa, I speak English. Agree with plh and mike. In addtion to the help from Mike, we have an agreement between the WHATWG and W3C. As part of the agreement, we have a HTMLWG in W3C, whose job is to facilitate this type of cross group work and we are the resource you can leap on, I'm one of the co chair with Leonie, please reach out if any difficulty
Wendy: thanks Tess, we are lucky to have to good working relationship with WHATWG and many people can help of the liason to raise issues, and that's way to get feature request and add APIs to the core and make the platform interoperable
angel: for interoperability requirements among MiniApp platforms, I think this can be discussed in W3C, might not need to bother WHATWG; for the browser involving part, it make sense to bring the discussion to WHATWG. Does it make sense?
Wendy: I think we are hearing it's not a bother for the WHATWG to accept new feature and new design that will benifit the HTML users boardly, so it's best we can work on design both in browser and out-of-browser HTML usage because things started one place may want to migrate to another. Developers and developing environment benefit from the consistency. The HTML WG in W3C is happy to help to set up the discussion, and Manifest can become an extension of the core spec, unique feature can be built as extension of the core HTML. Monket patching creates chanllege for everyone to sync on the work/core specs
<plh> the short answer is yes Angel. working on the differences of the overall lifecycle before diving into specific spec issues
PLH: want to say studying the differences of the two lifecycle models is a good start, if you look at the page lifecycle in WICG it's a patch of HTML and SW by itself, so it's not a spec to be potentially to move to the REC-track but to be ported to HTML
… we could define the gap and to map the differencies and then decide where is the next step
Wendy: thanks for everyone to share your opinions
… thanks Beihang team prepare this meeting
<angel> s/there is a interactive issue @@/for lifecycle specific interoperability among MiniApp platforms, I think this can be discussed in W3C, might not need to bother WHATWG; for the browser involving part, it make sense to bring the discussion to WHATWG
Wendy: I want to review tomorrow's topics
… hope we could have a detail future plan
… to resolve those specific issues
… and please think about what questions you want to realized from this meeting?
… any question?
… hope participants could watch the pre-recordings before next meeting
… thanks everyone