Re: [w3ctag/design-reviews] Web Install API - Same Origin (Issue #888)

Hola @LeaVerou and @plinss,

Thank you for your patience. I will try to answer your doubts to the best of my knowledge.

**Wrt `related_applications` and `prefer_related_applications`**

When referring to [`related_applications`](https://developer.mozilla.org/en-US/docs/Web/Manifest/related_applications), it is the developer the one that specifies that they'd rather have the app be installed from another place instead of, as you put it, "using itself as the source of truth". I 100% agree with your view. 

I believe this was more relevant when PWAs started in mobile and were mostly a run-down, "lite" version of the native/platform-specific counterpart. Similar behaviour is present in Safari when it adds a ["Smart App Banner"](https://developer.apple.com/documentation/webkit/promoting_apps_with_smart_app_banners) prompting that there is a related application on the App Store. I am **personally** not a fan of these behaviours, nonetheless, I believe if a developer prefers to have their app installed from the platform's app-repo, and explicitly adds the `related_applications` and `prefers_related_applications` fields to the manifest, then the installation should try to respect that. 

Now, I also believe this is up to the implementer if they want to honour that request the developer is doing. Safari does this with the meta tag `apple-itunes-app`. On the other hand, the proposal in WICG and documented in MDN WebDocs accomplishes this same behaviour through those fields in the manifest file, and if implemented into the official Manifest spec, would include support for multiple platforms, including the Apple App Store, Google Play and MS Stores. 

I put this in the explainer in the section of "Relation with other web APIs" as I think the installation flow could be different if these fields are present in the manifest file. Again, implementors could decide to ignore these or to implement different UX (like showing the install prompt with an option for the end user to choose where they would like the app to be installed from, for example). These are orthogonal to the API itself, and same-origin use cases are completely independent of the cross-origin ones. 

**Wrt same-origin parameters and `referral-info`**

The parameters are there as a way to pass more information if the developer needed. For example, with the `referral-info`, a user might be browsing in `siteA.com`, see an ad for appB, click on that ad that takes them to `siteB.com`, and `siteB.com` can retrieve the campaign id associated to that referral and pass it as a parameter when it is installing itself to remember a possible associated campaign effort. 

There is currently an [ongoing discussion](https://docs.google.com/document/d/19dad0LnqdvEhK-3GmSaffSGHYLeM0kHQ_v4ZRNBFgWM/edit#heading=h.koe6r7c5fhdg) about the requirement of `manifest_id` as a parameter for same-origin installs. At the moment `same-origin` could install any web content (as per Webkit's petition), whilst the option of allowing content with a manifest id only. I will promptly update the explainer and post back here once consensus is reached on this.

**Wrt to optional parameters**

I will update the explainer to reflect that it is a dictionary, not an object as it is currently stated. (and thanks for the heads up!)

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/888#issuecomment-2191838276
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/888/2191838276@github.com>