Deep linking - need proper use cases and requirements analysis

[marcoscaceres]

In https://github.com/w3c/manifest/issues/332#issuecomment-83960468, @PaulKinlan said:

Also deeplinking, the section in the spec makes no sense. Is there a plan for it to be expanded? I ask because Deep linking on Android has a very specific configuration, and I would expect to see some configuration of ownership of multiple paths, protocols etc (potentialy via a scope).

We should do a proper analysis of how this stuff works on Android. What is currently in the spec may indeed be insufficient.

[benfrancis]

See also https://github.com/w3c/manifest/issues/380#issuecomment-117821414

[alxlu]

Has there been any updates on this?

See also https://github.com/w3c/manifest/issues/380#issuecomment-117821414

If I'm understanding the comment @benfrancis made correctly, having the WebApp 'register' to handle URLs that are within its scope is how I interpreted deep linking as well. I think it's a promising way to handle deep links and definitely something to explore further.

It would be great to see if anyone has any thoughts about the potential downsides of this—particularly whether or not it conflicts with existing deeplinking solutions for native apps.

[kenchris]

I haven't unfortunately. @PaulKinlan, do you have anyone on your team familiar with the native deep linking who could look at this?

@alxlu as long as it is restricted to URL scopes within its own domain, I think this could work. The problem is when multiple apps register for the same scopes, but maybe that can be looked at as an enhancement in the future.

I would assume that registering for these scopes (and adding handlers) should happen in a Service Worker, as the app might not be running and because it gives a lot of flexibility.

We could then look at how to make the Service Worker launch the app in "web app state" - using the info from the manifest.

It is already possible to launch the app from the Service Worker based push notifications, but I would assume that that also just launches the app in the browser currently. @PaulKinlan can you confirm? We should really fix this.

[PaulKinlan]

I know native deep linking well. Will spend some time looming into a reply for this thread (sorry for this empty reply)

On Mon, 17 Aug 2015 09:50 Kenneth Rohde Christiansen < notifications@github.com> wrote:

I haven't unfortunately. @PaulKinlan https://github.com/PaulKinlan, do you have anyone on your team familiar with the native deep linking who could look at this?

@alxlu https://github.com/alxlu as long as it is restricted to URL scopes within its own domain, I think this could work. The problem is when multiple apps register for the same scopes, but maybe that can be looked at as an enhancement in the future.

I would assume that registering for these scopes (and adding handlers) should happen in a Service Worker, as the app might not be running and because it gives a lot of flexibility.

We could then look at how to make the Service Worker launch the app in "web app state" - using the info from the manifest.

It is already possible to launch the app from the Service Worker based push notifications, but I would assume that that also just launches the app in the browser currently. @PaulKinlan https://github.com/PaulKinlan can you confirm? We should really fix this.

— Reply to this email directly or view it on GitHub https://github.com/w3c/manifest/issues/363#issuecomment-131734446.

[benfrancis]

kenchris wrote:

I would assume that registering for these scopes (and adding handlers) should happen in a Service Worker, as the app might not be running and because it gives a lot of flexibility.

On Firefox OS we register the URL scope when a site is "pinned", it's completely orthogonal to Service Workers.

[alxlu]

Yes, I think it would be best to keep this independent from Service Workers for us as well.

[marcoscaceres]

We need to check what came of Balista.

[marcoscaceres]

@mgiuca, we should chat about Balista... I hear you are also in Australia (I'm in Melb), so that makes things a bit easier :)

[benfrancis]

I had a look over Ballista (which looks great BTW), but I don't think that's the same thing as deep linking.

Deep linking is about enabling hyperlinks for installed web apps, a fundamental feature of the web. It's about users being able to follow a hyperlink to a URL which falls within the URL scope covered by the manifest, other than the start_url, and for the manifest to be applied.

We have an implementation of deep linking using W3C Web Manifests in Firefox OS 2.5 so I can help provide use cases.

An example would be:

http://foo.com/myapp/manifest.webmanifest:

{
 " name": "my app",
  "start_url": "/myapp/index.html",
  "scope": "/myapp",
  "display": "standalone"
}

http://bar.com/page.html: <a href="http://foo.com/myapp/deep.html">deep link</a>

Clicking the hyperlink in page.html would navigate to deep.html and result in a browsing context with the manifest applied, so in this case it would have the standalone display mode.

A use case might be clicking on a link to a Facebook page from another website and that Facebook page opening in the installed Facebook web app, or following a link to a news article inside an installed news web app.

In Firefox OS we dynamically apply the manifest to the current browsing context when it is navigated to a URL within the scope of a "pinned" web app. I'm not sure what the UI for this should look like in other implementations like Chrome/Opera on Android where there is more of a distinction between app windows and browser tabs.

Ballista is different to deep linking because it doesn't use a hyperlink directly to a URL, there's a layer of indirection where it requests an "action" which could be handled by one of many web apps, of which the source app need have no knowledge. I have taken the liberty of filing a separate issue #442 for that.

[marcoscaceres]

So yeah, my definition (and maybe the one in the spec?) of deep linking matches what @benfrancis said. I guess actions are a kind of fancier deep linking.

[mgiuca]

I think I agree with @benfrancis here (though I'm not exactly sure what deep linking is in the context of a web app). Ballista (as we've been discussing it so far -- note that it is not a rigorous proposal at this stage) is all about sending a generic action with no specific target, and letting the user pick a target. Letting the requesting site send an action to a specific target could be in scope for Ballista but hasn't been on our radar so far.

@marcoscaceres I'd love to chat about Ballista. Note that at this stage we're doing experiments and thinking about the API. We aren't ready to talk standards yet.

[cvan]

The IPFS project's WebExtension browser extensions uses a custom manifest key called protocol_handlers.

Just thought I'd add some usage in the wild of a use case for a protocol_handlers key.

[marcoscaceres]

Should probably prefix that with “ipfs_” so it’s more clear it’s non-standard.

[marcoscaceres]

I'm inclined to close this and hold with current definition of a "deep link" (which is platform agnostic): A deep link it a link that is within the scope of a manifest.