Why not just web share?

[marcoscaceres]

Doesn't web share already cover these use cases?

In particular, Web Share already covers transferring file to anyone around you, in addition to sending it to other applications etc.

[marcoscaceres]

Expanding a little more as I read the Explainer:

"None of these solutions to this seemingly common task provide a compelling user experience."

this seems highly subjective, also because it fails to mention Web Share API.

For example: https://web-share.glitch.me

Already provides a UI for doing what is described in this API without needing to expose anything to the web page. This includes (but I've had to block out) my common share contacts, as well as direct access to AirDrop.

Using Web Share is way safer because from a security perspective because not only does it not expose anything to the web page, it also restricts the kinds of things that an be sent to other clients. It also already provides a super compelling user experience on multiple platforms (see Windows also, not just macOS and iOS).

So I'm a bit of loss as to why we one would want to replicate what's already fills this need in the platform with a new API?

If anything, is there anything more that Web Share itself should be providing?

[akbertram]

The explainer identifies a number of use cases that can't be solved with web share.

The challenge we face with web apps is included:

An app that allows humanitarian field workers in remote areas with no connectivity to gather, synchronize, review, and edit data offline for several days, the data can then be synchronized with the central server when internet connection becomes available

If I register a refugee family in an informal settlement without connectivity, I would want to be able to share that baseline data with a medical colleague who might provide medical services, without the availability of a central server.

Exporting the record to a file, and then using web share to send the file to someone else, who could then navigate to the right part of the application to import it, could work, but it's a lot of clicking. And it requires training field workers to do the whole sequence, which is slightly different depending on the phone that's being used.

[akbertram]

I should also note that web share doesn't provide any mechanism for two clients to negotiate which information is needed. The phones of two field workers ideally conduct a two way sync, so that each client shares the draft records that the other doesn't have. This would be possible with a native app, but not with a web app.

[marcoscaceres]

but it's a lot of clicking. And it requires training field workers to do the whole sequence, which is slightly different depending on the phone that's being used.

Right, but I can foresee a number of ways of solving for this without requiring a Web API at all. The Web API itself isn't the thing that solves for this. Imagine it would also have to work for all apps too. For example, you might have Google Docs (web app) and I might have the Google Doc native app. We might be able to solve for this via some kind of hypothetical virtual-networked local file system or whatever.

The fact that it takes a few clicks and training is not a compelling argument, as that can be solve for with better UI.

I should also note that web share doesn't provide any mechanism for two clients to negotiate which information is needed. The phones of two field workers ideally conduct a two way sync, so that each client shares the draft records that the other doesn't have. This would be possible with a native app, but not with a web app.

Two sites an do that independently of the API... like, if I have a Photoshop-like App as a share target, it's going to be pretty obvious what kind of data is accepts. Similarly, if a have some kind of medical app or whatever as a share target, I (as a user) know what kind of data I can send to it (because I installed it for that purpose).

[akbertram]

I'm not following - it sounds like you are saying this can be solved in the case where you have a web app and a native app on the same device that interface using the Web Share API.

If I need to have a native app - then in our case I wouldn't mess around with a web app. The goal here is to allow two web apps on different devices to exchange information without the need for a server to mediate the connection.

[marcoscaceres]

I'm not following - it sounds like you are saying this can be solved in the case where you have a web app and a native app on the same device that interface using the Web Share API.

No, sorry for not being clear... trying to clarify below.

If I need to have a native app - then in our case I wouldn't mess around with a web app. The goal here is to allow two web apps on different devices to exchange information without the need for a server to mediate the connection.

Right, I'm saying the opposite: Device A (Web App or Native App) -> shared data over wifi virtual file system <- Device B (Native App or Web App).

[akbertram]

What is a "wifi virtual file system" ? Is this something that exists today? Is it something that could work between two devices, or would I need to set up a WIFI access point that two devices could share?

I do think you are right that explainer should address Web Share API directly. (Edit: it does)

However, I have been thinking about it this morning, and I could see a partial solution for our specific needs:

1. Web app on Device A shares the link: https://www.example.com/import#BASE64ENCODEDPAYLOAD
2. User of Device A shares this link using the "Nearby devices" target.
3. User of Device B receives the link, which opens in the PWA offline. The JavaScript running on the /import page reads the base64-encoded payload from the URL fragment and prompts the user to accept and add to their drafts in IndexedDB.

Technically, you wouldn't even need the Web Share API at all for the above, the user could just long press the link. Though using the Web Share API could eliminate one step from the user interaction.

There are two limitations with this approach:

1. Data transfer limit. I don't know how much data we can pratically encode in the URL.
2. One-way communication. For two-way synchronization, the users above would need to both repeat the steps.
3. Continuous synchronization. Field workers would need to repeat these steps frequently during the day to keep their devices up to date and avoid duplicate data collection.

For the data transfer limit problem, the we could use the files argument to the Web Share API, but the user agent would have to accept a custom mime type, such as application/vnd.myappdrafts and implement the [file_handlers] (https://developer.mozilla.org/en-US/docs/Web/Manifest/file_handlers) property of the Web app manifest so the file would be opened automatically by the web app on the other device.

The other two limitations I think better highlight the fundamental differences between the two APIs.

Noteably, the limitations above could also be solved today with a native app, I believe. This proposal is about bringing the same capability to webapps.

[backkem]

The filesharing use-case is just one example mentioned in the explainer. There are more interactive examples, such as the local multiplayer game, that would not be solvable using Web Share.

In my view, the the crux of the proposal is that the browser can't do much on the local network without knowing IPs, Ports and accepting or ignoring a plethora of "Not secure" warnings. The goal is to make it possible again to build seamless, secure offline-first solutions with the user-friendliness on-par with what one can expect of cloud services. Chromecast to me is a good example of a seamless offline-first experience. Externalizing communication to manual file-management or externalizing rendez-vous by assuming there is a "wifi virtual file system" somewhat defeats the purpose.

[getify]

I guess I would compare this claim/question to...

Consider the claim that we don't need web sockets because HTTP already provides request-response semantics. You can shoehorn a lot of the communications into HTTP (and devs did for many, many years)... but web sockets was a far better design for a variety of use cases. It was not simply a matter of improving the API (or the UI), but we needed a fundamentally different kind of connection (persistent, two-way, zero imposed frame overhead, etc).

Representing communications between devices as files creates not only more overhead (which is wasteful and less performant), but it's also a confusing mental model for many of the use-cases (as already pointed out).

I think more importantly, Web Share is designed for the case where both users know that the data is being transferred, and they need a UI to grant permission. This requires the user to understand both that a "file" is being transferred -- which again, wouldn't make sense in most cases -- but also to make decisions on the receiving side about what to do with that file.

Many of the use-cases here are about creating a single trust connection between devices (which may or may not need OS-imposed UI for users to do so), then allowing the devices to transfer data in both directions, perhaps over time, without further user intervention. That just doesn't seem to map even remotely to how Web Share is currently exposed to users, and generally understood by users to work right now.

[yoavweiss]

Thanks @getify and @backkem for your insights! Maybe you can add something on that front to the explainer? (e.g. as a "considered alternative")

[backkem]

Yes, as also suggested in #20 we will look into separating the motivation from example use-cases.

[backkem]

Addressed in #20.