Re: [w3ctag/design-reviews] Incubation: PWA (same-site) Origin Migration (Issue #1164)

christianliebel left a comment (w3ctag/design-reviews#1164)

@mkruisselbrink Thanks for your proposal and for engaging with our questions. We're closing this review as **unsatisfied**.

First and foremost: We believe the underlying use case is valid. We agree that migrating an installed web application from one origin to another (or consolidating split apps) is a problem worth solving. However, we remain worried about the chosen architectural approach. We are not convinced that the proposed mechanism should be the web platform's standard solution for migrating installed apps.

We proposed to look at redirects as they are a common way to express moving resources. However, there are other ways to express local metadata, like the [Link Header](https://datatracker.ietf.org/doc/html/rfc8288). Using [site-wide metadata](https://www.rfc-editor.org/rfc/rfc5785.txt) (_.well-known_) for this does not seem like a good fit. We understand the edge cases you raised regarding "split apps" on the same origin, where no redirect is desirable, and we believe that this space may deserve a separate solution.

We understand that your proposal allows migrating away from a manifest-less app. However, requiring the destination app to have a manifest and an explicitly defined ID to enable this feature seems to reflect a single-engine's perspective. Specifically, it conflicts with the cross-vendor consensus that [any website is an installable web application](https://www.w3.org/TR/appmanifest/#installable-web-applications), regardless of whether it has a manifest. While we acknowledge the "ID footgun" and the trouble it causes for vendors, we believe that any requirement for a manifest ID in new features must first have cross-vendor support.

We feel that the proposed mechanism works backwards. Requiring the "new" app's manifest to host backward references (`migrate_from`/`install_url`) to the old app, while relying on a _.well-known_ file on the old origin for forward authorization, feels unconventional. Using _.well-known_ files for this purpose seems very different from a traditional web redirect. Also, this feature is coupled to other non-standardized proposals (such as reusing the Scope Extensions file name or the Predictable App Updating proposal).

We remain unconvinced that the manifest needs to dictate `"force"` versus `"suggest"` update behaviors. Defining UX behavior steps into User Agent territory, and UAs should retain full discretion over how and when to present which migration UI to the user.

We appreciate the effort put into solving this complex user journey, but we believe a solution more closely aligned with existing web primitives is required. We're closing this review now as we feel we've contributed what we can at this stage. Should you wish to continue the conversation, please feel free to reopen, and we'd be happy to pick it back up.

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

Message ID: <w3ctag/design-reviews/issues/1164/4461810624@github.com>