Description
another important thing to deliver (crosscutting the user stories) is a list of concrete features and APIs that we need to make this better
Background
What else ? How should these APIs look like ? What restrictions should browser pose in regards to these APIs ? Quotas like indexedDB ? Disallow reads across origins (across hashes ?) ? Should there be a form of CORS for IPFS content ?
I expect this to be a question with in first top 10 you’d be asked by browser vendors as long as you aim or “dweb apps”. if IPFS is a more positioned as distribution network of static files than that becomes less relevant.
In a separate conversation thread:
@jbenet
- For now, They can use js-ipfs to have a full ipfs node directly in the browser, or js-ipfs-api to use those APIs.
That sort of means "dweb apps" get unlimited power to read / write content, which I doubt is going to fly.
- We want to come up with a nice set of APIs to be provided by {addon, extension, webextensions} that js-ipfs and js-ipfs-api can cleanly polyfill, so adoption can just improve over time.
- Native APIs are the long-term goal.
I expect browser vendors to be more interested what APIs need to be exposed to allow “dweb apps”, implementation details are less important.