docs: (de-scoping) first pass at updating the IPFS in Web Browsers Roadmap #23
Conversation
ghost
assigned 
|
Is there any value we'd expect package mangers to get from having companion installed? I understand the previous proposals like creating your own website, saving a website snapshot, or p2p file sharing don't make as much sense given our top priority (though I'd LOVE to see more folks in the community pick up this work because it would be so cool - maybe write up a quick spec that someone else can implement?) - but curious if there's any 2019 work scoped for the extension. |
There was a problem hiding this comment.
- @momack2 given Package Managers scope, extension could detect the most popular JS libraries loaded from various CDNs, and work similar to decentraleyes, but instead of shipping code with itself just redirect to IPFS mirror at local node – Intercept URLs for JS libs at public CDNs ipfs-companion#674. Companion could also act as one of IPFS providers for IPFS-based JS CDN.
- We have open issues for various ipfs-companion features outside of package managers scope. Most of them is marked with "help wanted", some valuable design discussions are happening in comments, and small code changes are contributed to existing features. Unfortunately bigger tasks just hang in limbo for months, sometimes years. My guess is that webextension environment and APIs are not as familiar/attractive to devs as other ipfs projects. Some ideas (such as p2p sharing) will be moved to WebUI.
- I feel we should lay some low level groundwork for "website publishing" story in 2019 and reflect that in the roadmap. Right now it is missing.
Other comments inline below.
| - `M(P0)` Drop-in API Provider library is the default way of integrating IPFS with web apps and browser extensions | ||
| - `M(P0)` HTTP/WS /api/v1/ with proper access controls exists | ||
| - `M(P1)` Docs or guidebook of developer best practices for writing decentralised web apps exists. | ||
| - `M(PX)` It is possible to verify integrity of HTTP Gateway Responses |
There was a problem hiding this comment.
I feel this ability is highly relevant to Package Managers
- If package manager could verify integrity of packages fetched from HTTP Gateway using IPFS semantics alone, it would give additional incentive for adding IPFS support.
- See Verifiable HTTP Gateway Responses: Verifiable HTTP Gateway Responses in-web-browsers#128
This should be on someones roadmap for 2019. If Web Browsers WG not a good home for this, we perhaps we should move it to Package Managers WG itself?
| #### Foundation | ||
|
|
||
| - `M(P0)` Base32 CIDv1 is the default and can be used as authority in URLs | ||
| - `M(P0)` Drop-in API Provider library is the default way of integrating IPFS with web apps and browser extensions |
There was a problem hiding this comment.
Lack of good solution is this space is already hurting adoption. We really should address this in 2019.
This could be framed as a part of Package Managers' "Foundation", maybe something like this:
- Drop-in IPFS Provider library enables truly distributed CDN and becomes the default way of integrating IPFS into web apps
(In simple terms, we are talking about service worker that intercepts /ipfs/cid/some.min.js and loads it from the best IPFS provider at hand: js-ipfs, ipfs-companion, local go-ipfs, public gateway)
|
Let's park this for one more week 🙏 |
Following #21, this is my first pass/suggestions. @lidel, @hugomrdias please review