Pursuing this as an active proposal to the real spec

[jimmywarting]

i like this commitment in order to be able to create a own Blobs that can be back up with any source of your own choosing like a remote file.

Other possible places could be to create a Blob from that is loaded from multiple WebRTC peers.
WebTorrent have this File class that now also add some of the file WebIDL stuff like stream, text, arrayBuffer, name type and so forth.

The idea of being able to create a ObjectURL from them with URL.createObjectURL(blob-like) intrigues me.

• imagine being able to play a file that yet haven't been full downloaded yet and still being able to pass it down to the <video> element
• or to save this blob-like file to harddrive or indexeddb without having full downloaded it yet so it could start piping the data to it's destination. and then be garbage collected. like a one time use only. it would be like piping the response from a response.body down to indexedDB without having downloaded all of the content yet.

---

An early mention of this was posted already in 2017 here nodejs/node#16167 (comment) and here node-fetch/fetch-blob#99

to summarize you could return a Blob early without having to full downloaded the hole blob yet... given that the content-length is known and it isn't compressed.

---

There is also this issue where domenic suggest that you could await a stream to finish And once it's done you would get back a blob back (as an alternative method to new Response(stream).blob()
further down in that thread i suggested something like Blob.from({ ... }) that would allow you to create a real instance of a blob with your own source to back it up coming from any destination you like. it is essentually similar to this "web blob" but it would be more acceptable source as a data rather than being something that extends Blob and overrides the methods.
cuz internal api's should really be using public facing api's that may maybe be overwritten by developers.

---

So extending blob isn't something that really should not be working
you could dig down this rabbit hole: jsdom/jsdom#2555 (comment) of getting hold of a stream using internal private and public methods
but if some api's used publicly facing api instead then it could certainly open up a hole new world of possibilities.

---

chrome have several kinds of blob already: https://chromium.googlesource.com/chromium/src/+/224e43ce1ca4f6ca6f2cd8d677b8684f4b7c2351/storage/browser/blob/README.md

• Blob: This is a blob object, which can consist of bytes or files, as described above.
• BlobItem or DataElement: This is a primitive element that can basically be a File, Bytes, or another Blob. It also stores an offset and size, so this can be a part of a file. (This can also represent a “future” file and “future” bytes, which is used to signify a bytes or file item that has not been transported yet).
• dependent blobs: These are blobs that our blob is dependent on to be constructed. As in, a blob is constructed with a dependency on another blob (maybe it is a slice or just a blob in our constructor), and before the new blob can be constructed it might need to wait for the “dependent” blobs to complete. (This can sound backwards, but it‘s how it’s referenced in the code. So think “I am dependent on these other blobs”)
• transportation strategy: a method for sending the data in a BlobItem from a renderer to the browser. The system currently implements three strategies: IPC, Shared Memory, and Files.
• blob description: the inital data sychronously sent to the browser that describes the items (content and sizes) of the new blob. This can optimistically include the blob data if the size is less than the maximimum IPC size.

so the idea that you could create your own kind of blob would then also mean that it would be acceptable as any other blob part when doing

new Blob([
  virtual_lazy_web_blob,
  Blob.from({
    size: 123,
    slice(a, b) { ... }
    stream() { return ... }
  })
])

It would be really beneficial.

---

i could understand why it would be hard to implement cuz they also have to be transferable with postMessages.
reading such a blob in other thread would be hard, but i could guess it would be doable as long as the main thread who created it lives on, but still there are many issues getting this to really work neatly.

---

you could try to patch some things to use public apis instead. like overriding how FileReader.readAsArraybuffer(blob) read the content of blob to use the public blob.stream() instead. and you could override Request/Response/Fetch to instead create something like new Response(blob.stream()) and Requests did something like new Request(url, { duplex: 'half', body: blob.stream() }) and adding content-length header / type manually.

you could also try to override URL.createObjectURL(webblob) to return a own constructed url that a service worker intercepts. so the service worker becomes responsible for reading the content out of webblob and handing it to the <img> or whatever.

i could go on and on but i should stop there :P