#478: MiniApp URI Scheme

Visit on Github.

Opened Feb 27, 2020

Hello TAG!

I'm requesting a TAG review of MiniApp URI Scheme.

This is the first proposal from the MiniApps Ecosystem Community Group. The MiniApp URI scheme is a protocol that uniquely corresponds to a specific resource within a mini app. Mini apps are applications that run on the user agent and are based on Web technology combined with native application technology. This specification is supposed to work with the MiniApp package specification(under development) , which defines the form of resources in the mini app, as well as the specific path in the mini app and the mapped path relationship in the MiniApp URI scheme.

Further details:

  • [*] I have reviewed the TAG's API Design Principles
  • The group where the work on this design is being done (or is intended to be done in the future): MiniApps Ecosystem Community Group
  • Existing major pieces of multi-stakeholder review or discussion of this design:
  • Major unresolved issues with or opposition to this design:
  • This work is being funded by:

You should also know that...

[please tell us anything you think is relevant to this review]

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

Discussions

2020-06-08

Minutes

Yves: Same issue as the widget URL scheme previously.

... New URL scheme raises a lot of issues. ... Discussion going on on their repo. ... Need to realise the new URL scheme has a heavy cost. Can regular URL scheme give them what they want, using a manifest? What about media type?

Dan: Where is that feedback coming from?

Yves: Marcos has given some feedback. Currently discussed in their issue, linked from our repo.

Dan: Should the TAG have an official position on this?

Yves: We have already given that feedback...

Dan: Do we need to reinforce that? Noting that we have consensus on that view?

Sangwhan: I can leave a comment.

Dan: Need to be clear about feedback which represents consensus opinion.

... Let's chat in the plenary to make sure we have that consensus.

2021-01-Kronos

Minutes

Yves: feedback that it's not a good thing to define a new URI scheme. They will be exploring using https only. We can probably close that one. Especially now there is a WG in W3C, they will probably give us things to review once they have something back.

Sangwhan: URL scheme is not part of the charter?

Yves: something about defining a proper way to address mini app, that rules out URL scheme

Hadley: one of our early concerns was that they wanted to get rid of the same origin policy. Hopefully charter covers that as well?

Yves: that might be different. If they're using https there will be proper origin. They may decide to define a new security model, we need to be careful they are not doing that. But at least the origin would be there, compatible with the web platform.

Hadley: does this mean the first part of the scope includes the basic architecture and essential functions..

Yves: it's all the issues we have to review

Hadley: I had thought that what we were hoping for was each of those issues would be discussed with the rest of the web platform that's relevent. Manifest would be looked at in the context of existing manifest, packaging with existing packaging work (webappsec?), addressing with the context of URI standards in IETF? Is it likely that because those sectiosn are written separately to coordination that the WG will go off and do their own thing?

Yves: The goal was that manifest would be done in sync with webapp manifest. Addressing is more or less the same, it's about the URL scheme with implications on the security model, origin etc. Lifecycle there was discussion about aligning it with the page lifecycle work that is going on in W3C as well. Recognizing that there are different constraints in the miniapp world. At least being compatible on some part of the lifecycle.

Sangwhan: page lifecycle doesn't define PWAs very well so it's a good opportunity. And page lifecycle was abandoned, they could pick it up and fix it up. It's dormant.

Yves: I propose for the issues, now that there is a WG charter we should close those and wait for the next version from the WG.

Hadley: sounds good to me

Sangwhan: packaging is the really tricky one

Yves: When I looked it was mostly in relation with the work inside IETF Jeffrey Yaskin, secure exchanges thing. There might have been a need for delegating authority on the specific cached version, but the fact that addressing will work on that there is no need to add that in the packaging, they can use what they want. they currently are using a zip file and there's no need to be compatible with other packaging systems because there is no shared properties there. Discussion about packaging was look at other thigns and see if that fits and if not that's fine. Depends if you need some properties from them or not.

Sangwhan: rest of web platform has been pushing for signed/bundled exchanges but they don't work for this use case. The other part I'm concerned about is that they're using a zip file,which is bad for random access.

Yves: especially because the catalog is at the end, you have to download everything to start processing

Sangwhan: zip is not the answer for this kind of packaging. The alternative is signed/bundled exchanges and signed doesn't work for them and bundled is only halfway done. We've been trying to get a unified packaging format but I don't think bundled exchanges is ready to be promoted.

Yves: packaging is not what concerns me the most, it's reallye verything related to the security model. Addressing, lifecycle and of course manifest. We have to ensure there is no weird reason to do things on their own without coordinating with webapps.

Sangwhan: iw as concerned about their native widget embedding thingy, extremely scary. There's an API in one of their proposals. Hybrid rendering. Render a native UI component inside a webpage.

Yves: that could be 'interesting' for security.. A new WG has been created and they got oru feedback, so we can close the current issue and review again when thee's more. One week ago it was approved.

Hadley: difference between miniapps and PWAs?

Yves: the main diff is the installation process, and trust being in an app store instead of using only the origin to install the service worker.

Sangwhan: you can't currently preinstall a PWA, but supposedly you are able to pre-install a miniapp, otherwise none of the device vendors wold be interseted

Yves: a chat app, you can't in PWA rely on the fact the service worker will be always alive, can be installed every time based on constraint of the engine. Miniapp is mix of native app and webapp, you will always have the state of the chat application.

Sangwhan: the initial proposal contains some very powerful APIs like filesystem access. I don't think that survived into the charter aside from 'other components may be included by rechartering'

Yves: and about pre-defining specific web components

2021-06-28

Minutes

Yves: think we should close them and review when things are going out of the WG

Sangwhan: agree

Dan: [leaves note]