Identify Browser Features we Rely on or Want to See

[flyingzumwalt]

Delivarables:

• [ ] list of browser features we already rely on
• [ ] list of browser features we would like to see

[flyingzumwalt]

@lgierth do you have any ideas of initial things to put in these lists? @diasdavid? @jbenet? @dignifiedquire?

[dignifiedquire]

What we use

• websockets
• webrtc data channels
• webcrypto
• webworkers (trying, not fully there yet)
• asm.js
• xhr
• fetch

What we want

• webrtc data channels in webworkers
• better suborigin spec
• some enhancements for webcrypto
• streaming support for fetch
• cancel support for fetch

[ghost]

stuff we use:

• websockets
• webrtc data channels
• @ipfs/javascript-team what else? localstorage? webcrypto?
• suborigins

stuff we'd like to see

• support for first-class origin-less content (we're figuring this out this sprint)
• dns resolution api, instead of deferring to the browser
• unreliable webrtc data channels (chrome might already implement it)
• more webcrypto
• custom protocol handlers (ok in firefox, only with web+ prefix in chrome)
• consistent ipv6 usage (inconsistent RFC6555 impls, no ipv6 at all in chrome if no ipv6 connectivity to google.com)
• ...

[dignifiedquire]

Updated my comment to be a bit more specific

[kumavis]

I've seen some automated tools out there that parse code for web api usage, can't remember any sepcifics

[kumavis]

streaming support for fetch

I believe this is a thing. just some weird browser standard promisy pull-stream like thing. poor adoption currently.

https://developer.mozilla.org/en-US/docs/ReadableStream https://developer.mozilla.org/en-US/docs/ReadableStream#Browser_compatibility

fetch('/big-data.csv')
.then(function(response) {
  var reader = response.body.getReader();
  search()
  function search() {
    return reader.read().then(function(result) {    
      if (result.done) {
        // ...
      }
      return search()
    })
  }
})

[dignifiedquire]

@kumavis it's a thing, but only usable in Chrome, so it's like it doesn't exist effectively

[daviddias]

@dignifiedquire @lgierth awesome list!

One more thing we use:

• IndexedDB

What we also want:

• drag and drop of directories

[jefft0]

An IndexedDB connection can only access databases associated with the origin of the global scope from which the connection is opened. If the browser thinks the URI of an IPFS page being viewed is a different origin than another page, then they can't share an IndexedDB database, such as cached IPFS blocks. I'm curious, have you found a way around the origin restrictions?

[haadcode]

Adding to the list of features we use (front end side):

• MediaSource - Currently the only way to stream audio & video from js-ipfs and the implementations in browsers leave much to desire (although I haven't had much problem in Firefox, usually in Chrome). Essentially what we want here is to stream chunks of data (directly from js-ipfs) to video/audio dom elements, with buffering and seeking (offset) possibilities.

Want to use in the future:

• MediaRecorder

[kumavis]

@jefft0 could make a special gateway that works like this ${cid}.ipfs.io/index.html edit: except the cid would need to be in a case-insensitive encoding

[jefft0]

@kumavis I believe the same-origin policy requires the entire host to be the same. So the different ${cid} would make it a different host and origin.

[kumavis]

@jefft0 Oh ok I misunderstood which you wanted (isolation vs unification). I have a project that exposes the ethereum blockchain app api to a webapp and unifies the cache inside an iframe. Seems like something similar would be useful here.

[small ipfs-iframe lib] <-> [ipfs node in iframe] <-> [network]

We're also exploring making the node a singleton by using ServiceWorker.

[small ipfs-iframe lib] <-> [ipfs iframe proxy] <-> [ipfs node in serviceworker] <-> [network]

I'm sure theres a few gotchas with this approach, especially that webrtc may not be available in the SW.

[ghost]

@haadcode @VictorBjelkholm @Kubuxu did anything come up in the windows.ipfs work which would be worth adding here?

[victorb]

@lgierth I'm currently having issues that sure, could be easier but after talking with web extension people at Mozilla, things should be able to work. Mainly I'm having troubles passing down objects created in background-context to the web page, but we should be able to work around that.

[ghost]

Support for DNS lookups or at least TXT lookups was rejected on the mozilla tracker: https://bugzilla.mozilla.org/show_bug.cgi?id=1343849#c3

[lidel]

Pushing support for DNS TXT once again, this time on the shoulders of newly added WebExtensions API:

• https://bugzilla.mozilla.org/show_bug.cgi?id=1449171