Share blobs via a Blob URL?

[mgiuca]

There should be a way to share large blobs / files using the Web Share API.

Couple of ways to do this:

• Add a blob or file attribute to the share data object, allowing such objects to be added directly.
• Set the url attribute to a Blob URL to reference a blob.

The latter approach is nice because it keeps the API surface small and forces you to share just one piece of content (either a web URL or a Blob URL, but not both). This may or may not be desirable.

[rektide]

On the one hand I think this is a smart, intelligent use of the web platform and provides a great deal of flexibility. There's considerable merit to this idea.

But this idea also gives me great pause & concern. I do really like that web share shares URLs, shares resource locations. When an (web share) target is in charge of opening a photo, it's not just a photo blog it gets- it gets a url. And that allows for all kinds of interesting exchanges to happen- Host Meta, Web Manifest, &c on the host, using XRD to get info on the image. And if the target wants to talk to any other web systems, it knows who and what it is trying to talk about. Sharing URLs keeps an essential web-ness to the sharing that blobs can not preserve.

Certainly shared blobs could act as containers with links in them, but it's not, by default, a web share if it's a blob.

The implementation path is far less clear, but I would enjoy seeing something like #11 where the browser could have a ServiceWorker serve large blobs to the target, perhaps by acting as an HTTP proxy to the target if it is an app or just via foreign fetch as normal if the target is a web target.

Specifically this ticket is about letting the browser share large content. The browser has to have the data to make the URL. So it makes sense to me to use the caching mechanisms built into the browser to hold that data. If the target is a web target, there already is a very efficient way to share large blobs- use foreign fetch to serve that data. There ought be no need for this feature on a foreign-fetch browser, for people willing to expose the data they are trying to share in Service Workers. What is needed is a way for non web targets to still have a way of getting data from the browser. I tend to think having the browser provide an HTTP Proxy to the app could solve this last leg nicely.

[mgiuca]

Hi; I responded on #11 about offline support. I don't think that's feasible, which means sharing blobs is the only way to have Web Share pass the actual data to a native app while offline.

I think we can carefully extend the spec to allow metadata as well as blob data. For example, you could share a photo and it would be:

{
  "title": "My cat",
  "url": "https://example.com/photos/cat1.jpg",
  "blob": [Binary blob data],
}

That way the recipient app can access the image data directly, even when offline, but also has the URL to fetch more metadata, create backlinks, etc. I don't want to hold back on being able to share binary data because of concerns that it makes things "less webby".

[terales]

I love idea of having url alongside blob data.

But standard JSON can't store binaries.

ECMA-404 The JSON Data Interchange Standard, 2013, page ii:

JSON is not indicated for applications requiring binary data.

ECMA-404 The JSON Data Interchange Standard, 2013, page 2:

A JSON value can be an object, array, number, string, true, false, or null.

Maybe we should share a "photo" in base64 encoding? It has wide support in both web and native mobile.

[mgiuca]

Web Share data objects are not JSON. JSON specifically refers to a string encoding of an object structure; we never encode it in a string. The interface we provide is a DOM function interface that can take an arbitrary object.

If a Web Share implementation needed to use JSON to transfer the data then they could work out an encoding scheme such as base64, but that would be outside of the scope of the Web Share API itself.

[rektide]

@mgiuca Suggesting that if Web Share implementations need to use JSON to transfer, they have to invent their own encoding practices seems well outside your suggestion about how we still keep it be URLs that we share.

Moving away from URLs by default seems expressly un-web. Having to define your own base64 transport to use Web Share to share a blob+url seems like a way to insure no one will ever be able to interoperate together ever. And since this feature could end up required for offline support, that seems really scary to me.

[mgiuca]

@rektide I don't understand your concern. You seem to be suggesting that URLs are "webby" and Blobs are "non-webby". But there are lots of web technologies that use Blob objects. You should just think of a Blob as another data type that JavaScript functions can accept. Blobs can't be encoded in JSON, but there is no rule that Web APIs have to accept JSON-encodable objects. Using JSON doesn't magically make things more interoperable.

Suggesting that if Web Share implementations need to use JSON to transfer, they have to invent their own encoding practices seems well outside your suggestion about how we still keep it be URLs that we share.

In my previous comment, I was specifically talking about Web Share implementations (i.e., browsers), which might perform their own internal processing on the data, or might need to reformat the data to interoperate with a pre-existing standard (such as the Android intents system). Both of those are outside of the scope of the web standard because they relate to how the browser deals with the data after it goes through the standard interface.

Having to define your own base64 transport to use Web Share to share a blob+url seems like a way to insure no one will ever be able to interoperate together ever.

You seem to be thinking of Web Share as a network protocol (and network protocols need standard transport formats or else two different implementations can't talk to one another). It isn't. It's a JavaScript API. All we need to do (at the standards level) is define what methods are available, what their argument types are, and what they are supposed to do. We aren't defining any serialization format and we don't need to, because these objects just reside in one browser's memory --- they are not transferred between computers or browsers. The only time serialization might be required is if the browser wants to share to a native app (via a pre-existing OS-level share protocol), such as Android intents. At that point, you have to marshal the data into another format, but that will be different for each operating system, and again, that format is outside of the scope of this proposal.

Example 1: Web to web sharing (with Web Share on one end and Web Share Target on the other). Both sites are going to be communicating via a JavaScript API. You put a Blob object in one end, and a Blob object comes out the other end. There is no need for any serialization (other than, maybe, the browser internally performing its own serialization, which is an implementation detail).

Example 2: Web to native sharing (with Web Share on one end and a native app receiver on the other). The user agent needs to figure out a way to present the Web Share data object in an appropriate way for the host operating system. This might involve some serialization: for example, on Android, we need to write the Blob to a file on disk, get a special (Android-specific URL) that refers to that file, and then pass the URL inside a Java data structure. But this process is totally outside the scope of the Web Share standard; it's up to the browser to marshal the data between the Web Share data structure (which can be whatever we decide, e.g., a Blob object) and the Android data structure. It wouldn't matter if the image on the Web Share side was a JSON-encoded-base64 string, a Blob URL, a Blob object, a Uint8Array, a CanvasRenderingContext2D, etc. The browser still has to marshal it into the operating system's required format.

The point is that whatever encoding the user agent needs to do to on the data supplied to navigator.share is an implementation detail for that user agent, and has nothing to do with interoperability. All we need to do at the spec level is define a standard JavaScript interface, and there is no need to arbitrarily restrict ourselves to JSON.

(Note: Despite what I said above, I am not committing to adding a Blob attribute. The original question posed in my issue description is still an open question: whether to directly add a Blob attribute, or use a Blob URL as a proxy.)

[PaulKinlan]

Would love to see blobs as a solution. A lot of Android apps use content urls to open the file and read it in (that is probably not safe here), but one thing we were doing with Web Intents was to allow you to clone a Blob and either pass a copy or pass a reference (transferable object) and the recieving app would be able then to read the blob data.

I could totally see this working along the lines of us detecting the blob and then put the blob on the EXTRA_STREAM extra on the Android intent to be able to read it out.

[mgiuca]

@PaulKinlan Yeah we can certainly do that but I want to make sure this will actually be useful. Is there a use case for transferring blobs outside of sending images?

As discussed in #12, sharing blobs isn't necessarily going to work for sharing images, due to CORS. It is very common for pages to be unable to read the bytes of their own images (which are served from a CDN), and therefore would be unable to convert their images into a Blob for sharing. Therefore it would be more useful to be able to share images by URL, not Blob.

Is there a compelling use case for sharing a Blob?

[henrydawson]

I'm not sure if it's compelling or not, but I'll give you a quick rundown of my use case (It's quite similar to the needs of @ipeychev listed in #12).

I'm creating a PWA in which a user takes a photo or video, and then applies art filters to it, similar in essence to Prisma. The content is created in a canvas. The user then has the option to save or share content. We provide the user with options for how they want to export the file (e.g. resolution and file format), and then we create the final file for them. Currently, we initiate a download of the file for them, but ideally we would like to use the Web Share so that users could seamlessly share their content, through Instagram or any other app.

For us, I think sharing blobs would be ideal - perhaps even better than the Image abstraction in #12. This is because we already deal with blobs for the file downloads, and we support exporting of SVG files as well as PNGs, and hopefully videos in the future.

I think having the ability to share blobs would be a huge boost to the web and PWAs. I know in my case, I'm (reluctantly) planning to wrap my web app in a native shell just so I can get access to native sharing - that's literally the only native feature I need. If Web Share were to support blobs, then I will very happily stay just as a PWA.

[nektro]

+1 for Blobs over #12 since over time, web apps will share more than just Images and would love to see this in the API. One note, is that WICG/web-share-target is also going to need a way to specify the Blob.type types they are allowed to receive.

[mgiuca]

This is fixed in the Level 2 specification: https://w3c.github.io/web-share/level-2/

Keeping this bug open because it still needs to be condensed into the base spec.