#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

Comment by @cynthia Feb 28, 2020 (See Github)

(NOTE: Not a full review)

The explainer only contains a what (in terms of solution), and lacks a problem definition and use cases that motivated this work - could you take a look at our explainers explainer and revise? Ideally, it would be a separate document; not a blurb in the spec.

Possibly blunt but curious question - it seems the "dereferencing" process ends up with a standard HTTP(s) URL. Wouldn't using that as is make it more accessible to end-users? This would trip unless you have a runtime (which would be also presumably, be a browser) - it feels like this tripwire mechanism's main motivation is to make the user install the runtime (in which case, what does this runtime provide that the current browser does not?), which I'm not sure is something that I personally would agree with.

Comment by @siusin Feb 28, 2020 (See Github)

Thanks @cynthia !

@Sharonzd could you prepare a explainer for this document?

Comment by @Sharonzd Mar 2, 2020 (See Github)

Hi, Cynthia, If I had misunderstood your question, please tell me.

I understand your question contains two points,

  1. Why not directly use the HTTPS protocol as the MiniApp URI?
  2. The current MiniApp URI mechanism requires a set of runtimes to parse it. Why is it necessary? What is the difference between that runtime and a conventional browser?

For point 1, downloading a package through the network is just one of the ways to get a package. In addition, there are many ways to access a miniapp resource:

For example, after accessing the miniapp once, the miniapp package would be stored locally. Or the user agent can preset the miniapp package before the user accesses the URI for performance (as we mentioned in #2.1.6 of the miniapp white paper ). Or when debugging the miniapp, the developer can directly push the miniapp package to the user agent through a debugging tool.

In these cases, the user agent open miniapp locally according to the appId in MiniApp URI without having to request a package server.

In other case, the user agent can specific its own mapping relationship with "host" component. For example, the "bar" in "miniapp: // foo @ bar" can correspond a domain or a local directory, anyway.

In summary, MiniApp URI are designed to locate MiniApp resource cross-platform, regardless of how they are obtained.That cannot be expressed intuitively through HTTPS URLs only. This is why we mentioned in Chapter 6 Use HTTPS that it is non-normative, and it just describes a user scenario.

For point 2, the runtime make miniapp can help to fill the gap of the Web and the Native.(like we mentioned in miniapp white paper introduction. And because the design of the MiniApp is different from traditional web applications (like we mentioned in the core-features the miniapp white paper)). Even if the miniapp packaged is downloaded by a traditional browser, it cannot be opened and run.

And with the necessity of the MiniApp URI demonstrated above, therefore, browsers need to implement MiniApp URI specifications to correctly parse MiniApp URIs and implement MiniApp runtime related specifications (under development) to open and run MiniApps properly.

Comment by @cynthia Mar 3, 2020 (See Github)

@ylafon and I looked at this during the Wellington F2F. Based on the proposals, we have some technical concerns.

First of all, it is generally not a good idea to invent a new scheme (Also: https://www.w3.org/TR/webarch/#URI-scheme). The motivation described in the initial round of feedback we got was around performance and pre-installation. As for performance, browser caching mechanisms and plumbing provided for PWAs should provide the necessary mechanisms needed, if there are uncovered use-cases or patterns, it would be best to address those by improving said specs. Currently, it seems like the main motivation for the custom scheme is to trigger loading through the runtime, which we believe can be achieved through content types (see Webarch) and URI templates. We saw this pattern used in the QuickApps URI templates in the explainer; it would be useful to know why that was not considered.

As for pre-installation - unless there is a story around preserving the trust chain, we are not sure how this would work. Pre-installation mechanisms without any validation of provenance can undermine the integrity and guarantees of delivery through HTTPS.

Could you please provide us with some details on how you plan to address these issues?

Comment by @cynthia May 26, 2020 (See Github)

Friendly ping - any updates?

Comment by @Sharonzd May 30, 2020 (See Github)

Sorry, here are the latest updates: https://github.com/w3c/miniapp/issues/34

Discussed Jun 8, 2020 (See Github)

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.

Comment by @cynthia Sep 23, 2020 (See Github)

@ylafon and I discussed this during our "F2F". It seems like work is going in the right direction, but not yet at a point where we can do further review. We'd be happy to take a second look when there is something for us to review.

Comment by @xfq Nov 16, 2020 (See Github)

The CG (and/or the proposed WG) will rename the spec to "MiniApp Addressing" and rewrite the spec to reuse http(s). See:

Discussed Jan 1, 2021 (See Github)

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

Comment by @cynthia Jan 26, 2021 (See Github)

I was told by @ylafon that the direction has changed (for the better) so we think our work is done here. We're happy to see the new direction that group has taken for this particular issue, and we're glad to see this move forward. Thank you for bringing this to our attention!

Discussed Jun 28, 2021 (See Github)

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

Sangwhan: agree

Dan: [leaves note]

Comment by @torgo Jun 29, 2021 (See Github)

We're going to close this for now and we look forward to reviewing when you have a new proposal.