<inserted> scribe: chaals
Angel: Have you read the miniapp paper?
... [ about half?]
Slide: recent progress
... MiniApp is everywhere
... MiniApp helps to solve problems like…
slide … the Web.
QA: Web is not as capable as native platforms
slide: what is MiniAoo
QA: Miniapp gives providers more options to distribute their app
slide: case study
<jv> can we have a link to the slides plz
slide: case study 2
... case study 3
QA: You can use miniapps on systems like vehicles ,or smart speakers
slide: core features
QA: provides a native-like experience for developers.
slide: Core features - data flow
... MiniApp widgets
QA; so you can put a piece of information on the main screen, and then go into the miniapp from there.
scribe: widgets an call into other miniapps.
slide: security and privacy
... things we want to standardize...
LZ: MiniApp can be launched from anywhere, so what is the difference?
... inside a package, so you download it once.
... Vendors have agreed on the file structure. We can describe how to create, parse, compress and decompress a MiniAppp
slide: URI scheme
... navigation of MiniApps is important so we should define a MiniApp scheme.
scribe: packaging is critical, the next bit is about improving the experience
slide: transition animation
slide pull-down refresh
LZ: So user can get good experience for updating. This is hard in JS, would like a simple native way to do it.
slide: life cycle events
LZ: We have onload etc, but there are some more things we want.
... e.g. after quitting an app it stays sort of alive in the background so you can instantly reload it.
slide: scrollview
LZ: these last are high-level components to make miniapp feel more like native apps.
slide: MiniApp widgets
LZ: user wants the widgets so they can do some work without being activated.
[more detail about mini app widgets https://www.w3.org/2019/09/Chinese_IG/miniapp_widget.pdf]
QA: Some other requirements - allow native components to render in a min app
slide: native rendering
... other ideas
... next step - explore innovation
QA: Thanks you
ChrisLilley: can widgets also be displayed inside other apps?
[yes]
CL: So can a widet get user interactions in the app? How do you do the sanboxing?
<Zakim> ChrisLilley, you wanted to ask "Can widget display inside another MiniApp?"
Zhiqiang Yu: Widget cannot be display in another MiniApp. Can be embedded in a hosting app
scribe: after you click the widget, the MiniApp pops up. At the moment...
... would be interesting to see if we can embed widget, but it is worth exploring
JudyBrewer: Noticed in white paper there is a section on security and privacy. What about accessibility considerations? My understanding is MinApps do not use the DOM, but that might be possible. in future...
QA: currently the DOM is not open to developers, it is possible in MiniApp platforms we add more capability to access in teh future
... developers are willing to look carefully at accessibility.
JB: Are there ways W3C can help make MiniApp and superapps more accessible?
<torgo> I will discuss the manifest file format : https://www.w3.org/TR/appmanifest/ as part of a possible convergence path with Progressive Web Apps (PWAs): https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps
JudynogruZhu: We don't have a roadmap for accessibility but we can discuss this it is important
DanAppelquist: I already shared some feedback informally, I would hope the MiniApp community in W3C leads to significant convergence between miniapps and the W3C stack work on progressive web apps.
... using manifest, service worker. I saw that miniapp is a package that looks like a manifest of assets. We have been working on this for a long time as a standard…
<KenjiBaheux> +queue
DanAppelquist: good way to start converging is to adapt W3C manifest file, and send requirements on that as needed.
... that is happening in webapps group. I think that is the way forward. There should be convergence path, not just throwing away miniapps work.
JeffJaffe: I'm impressed with how the work has progressed.
... half a year ago there were about 100 features and not much clarity on what we needed to do, and today there was a very succinct list of what to do.
... similar to Dan - but as a question: what is the maturity level of the current miniapp work. Does this need to go through incubation, or is it mature - can it be developed in a WG or merged with existing work?
LiuDaPeng: to answer, from technical perspective there are a lot of technologies already mature enough and deployed, but we probably need some discussions about how we can move forward.
<angel> ?
LiuDaPeng: think there could be two approaches. set up a WG - the requirements are clear, the technology is mature enough. We could also have a place for incubation - discussing what kind of work we can spatch to reuse existing work in established WGs.
... both can work but we probably need more discussion.
ZHR: Would like to clarify - how mature is "mature"? MiniApp is very popular in real market in China.
... we need incubation stage also, in miniapps there are additional features that are not ust features of the web but are unique.
... if it isn't at W3C we can always just do it in china. But if we go forward doing things here and get features in PWA work that can work out, but there are other features not suitable for PWA.
... so we appreciate suggestions on how to move forward.
JJ: in terms of maturity, understand it is powering China - it is useful and mature. But there is also a question on the maturity of interoperability. That's part of the question too.
LDP: yes, we an implement the functionality but we have some room to improve performance. And on interop, that is not mature enough yet.
... that needs standards work to improve the maturity level.
Zhixing: There are about a million developers making apps in China. Vendors are sharing traffic through miniapps, so developers in small companies are keen to develop miniapps.
KenjiBaheux: to echo something Dan mentioned - there are pieces that feel very close to things that are being worked on - web packaging is one I care about. I would like to know if what we are doing there doesn't work for you, and see if we can fix it because it seems the use cases are very close.
qingqian: Web packaging as I understand is a serverside technology. Website can use it to improve performance and cache content on different origins. Maybe miniapp can use web packaging, to improve distribution performance.
<xiaoqian> Web Packaging https://github.com/WICG/webpackage
qingqian: but miniapp needs to resolve the problem that miniapp packaging has no origin. vendors should provide an origin an we can use web packaging. Or web packaging can support miniapp without a domain…
<whsieh> (oops)
LZ: Miniapps can be distributed to stores.
... so major difference is coming to a store and don't need installation. With some control you can choose better security. on another side, deploying to a specific store, you can enable some optimisation
... improving user experience.
LDP: Web packaging intends to run web content in browsers, but miniapps can run on different kinds of platform.
<Zakim> ChrisLilley, you wanted to call for a clearer description of capabilities of the hosting superapps
CL: White paper is well written - thanks. But it assumes you know what a super app is - it would be helpful to explain more about a super app that can host miniapps, so people can see how it is different to a web browser.
Angel: Thanks, good feedback we will look at doing that.
WinsonHsieh: If I am at a site, and install a miniapp, can the website find out whether its miniapp has been installed by a user?
LZ: Currently no. But many programs exist so we could release the API to developers
<jUdy_zhu> q?
DA: Following from Kenji, agree that it would be good to look at web packaging. You talked about origin. From a technical architecture, origin is critical to the web.
... a lot of the security properties of the web depend on the origin, so would suggest that we find a way for miniapps to have an origin.
... that will allow it to unlock web capabilities like storage...
<Zakim> torgo, you wanted to talk about the importance of origin in the web architecture.
<KenjiBaheux> +q
LZ: yes. We found that origin thing is important. We have no cookies, no storage, …
... we implemented miniapp storage as a workaround. But we have ha no way to improve things. We have an isolated sandbox for miniapps.
... so they have a private key to get some essential items. THis is a workaround I think.
TQQ: The difficulty with origin is runtimes do not have a URL available, so we cannot base on that.
... in mobile, native apps don't have URL access. so maybe we can use origin to download miniapp, but it is not useful for native app to access miniapp. This is a product issue. Technically, maybe we can transfer the miniapp to having a URL to access it, but native apps can't have that.
KB: origin is important - you had a slide with miniapps ending up in walled garden. as long as you cannot find a miniapp in an open place I don't see how you can solve the walled garden issue. Origin is a way to maintain an open system.
DA: motivation for these comments is thinking about a developer. If they want to make a miniapp, and know they can reuse their PWA for a miniapp or vice versa, it helps the web by helping them.
TQQ: Consider search engine or similar. URL is very useful.
... we are also trying to find an efficient way to do it. Baidu has a technique, but not all miniapp vendors support the technique so maybe this is a next step.
Qing_An: normal web properties can run into that problem.
JJ: Big topic for one hour, but there is more work to do: W3C Team is interested in continuing the conversation with miniapp team, PWA vendors, TAG.
<KenjiBaheux> [clearer version of what I said] Another reason why having an origin/url is important: you had a slide with "walled garden" as a downside of the current form of miniapps. As long as these apps can't be found and indexed in an open place, I don't see how you can solve the walled garden issue. Origin is a way to maintain an open system. It would be good to get it back even if today's mini-apps don't have such concept. Or perhaps you have other idea[CUT]
JJ: Chris Lilley, Xiaoqian, Fuqiao can help move the discussion forward.
Angel: Chinese IG has some clear ideas but think there are some details missing. Good time to tell us if you have conerns or suggestions. We know there are some areas we can collaborate with that overlap.
Angel: look at the plan we have, and see if you have comments. And companies with similar plans, please collaborate.
... are there other options you can think of?
CL: the question about maturity. There is vast deployment - what should happen has been prototyped. This is not unusual stating point for a WG to get towards interoperability, so long as there is willingness to change implementation, I don't see why we should not start a working group.
DA: suggest a CG, and think about what elements can be associated with existing W3C working group items. Manifest is being developed in WebApps, meeting this week.
... there are some others. Would love to see requirements on existing work that map onto what miniapps do
<xfq> Mini App Standardization: update and next steps in AC meeting https://www.w3.org/2019/09/TPAC/ac-agenda.html#thursday
ZHR: Appreciate suggestions. Some people have talked offline too. Tomorrow there will be a session at AC. For us if the goal is to resolve the interoperability, and meet Chinese requirements, we don't need to come to W3C.
... W3C is global, needs to include Chinese market too.
... A CG does not define standards. If you can satisfy existing requirements that would be great. Will think about whether we want a CG or WG…
Angel: Thank you all for comments and suggestions
[+1 to CL, think a WG makes sense assuming there is willingness to change implementation to match a new spec (and/or other existing ones)]