MiniApp URI Scheme

[siusin]

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.

• Explainer¹ (minimally containing user needs and example code):
  https://github.com/w3c/miniapp/blob/gh-pages/specs/uri/docs/explainer.md
• Security and Privacy self-review²:
  • https://w3c.github.io/miniapp/specs/uri/#security-considerations
  • https://github.com/w3c/miniapp/blob/gh-pages/specs/uri/docs/explainer.md#5-security-and-privacy-considerations
• GitHub repo (if you prefer feedback filed there):
  https://github.com/w3c/miniapp/
• Primary contacts (and their relationship to the specification):
  • Dan Zhou (@Sharonzd), Baidu
• Organization/project driving the design: Baidu
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status):

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

[cynthia]

(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.

[siusin]

Thanks @cynthia !

@Sharonzd could you prepare a explainer for this document?

[Sharonzd]

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.

[cynthia]

@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?

[cynthia]

Friendly ping - any updates?

[Sharonzd]

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

[cynthia]

@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.

[xfq]

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

• https://www.w3.org/2020/10/15-miniapp-minutes.html
• Rename URI Scheme to Addressing w3c/miniapp#134

[cynthia]

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!

[torgo]

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