Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Sprint: IPFS in Web Browsers #351
Main Repository: https://github.com/ipfs/in-web-browsers
Team for this Sprint
This is part of the overall Path to Native Browser Support described in the Roadmap for IPFS in Web Browsers
Priority for this Sprint: Get everything lined up on our side so that the tech is ready for browser manufacturers to evaluate and so that we're ready to build the case for browsers to support IPFS natively. If we lack strong, complete stories/arguments and demos at the end of this sprint but do have all the tech sorted out, that will be a good finishing point for this sprint because it will put us in the right place to proceed with our next steps in the coming months.
Driving question: What do we need to do in order to ensure that IPFS is usable by web applications without bundling IPFS into those applications and without running a separate IPFS daemon on their users' machines?
To see the open/closed status of these issues, visit the Milestone for this Sprint
Objective: Document the Effort to Get IPFS into Web Browsers
Provide Ways for people to understand this effort and Follow the Work
Objective: Enable people to install Protocol Handlers in their Browsers
Create browsers add-ons and/or extensions that handle decentralized web protocols. These browser extensions / addons should inject IPFS into the browser context so developers can access it without having to bundle ipfs in their applications.
Definitely implement these for Firefox during this sprint. If possible, create them for Chrome as well.
Objective: Improve Infrastructure as Needed
Make the components involved here WORK FLAWLESSLY. When someone on a browser team opens a demo or runs some code, it has to work perfectly.
Objective: Create Specs for the Protocol Handlers
Document/Specify the APIs, address schemes, security models, etc. necessary for browsers to adopt IPFS
Objective: Prepare to make the case for IPFS in Browsers
Some of this will be covered in the Delightful Documentation Sprint later this quarter.
For a broader sense of the next steps, see the Roadmap for IPFS in Web Browsers. Our main next step will be:
referenced this issue
Feb 7, 2017
Is this call open to the public (me) to listen in? Will the link be on the public calendar? https://email@example.com
Apologies. I've forgotten to record two calls in a row -- the Sprint Planning Call and today's standup. Here are the notes.
Notes From Sprint Planning Call for IPFS in the Browser Sprint
Moving into the issues
Notes from Tuesday 14 Feb Standup call
Apologies for forgetting to record this
Participants were @flyingzumwalt, @lgierth and @whyrusleeping. The waffle board shows what we're working on. We just focused on the "improving dependencies" issues. Concluded that those issues will probably take at least the full sprint to handle, especially since we will have to handle websockets and routing.
We spent an extra 15 minutes looking through the backlog and making sure the work is explained clearly. This is because @flyingzumwalt won't be available to groom the issues & board Thursday-Sunday this week so we want people to be able to pick up assignments on the fly.
The major update from today's standup call and the discussion that followed in ipfs/in-web-browsers#39: We rearranged the issues around creating the protocol handler so it's clearer what work needs to happen. See https://waffle.io/ipfs/in-web-browsers?label=protocol%20handlers
Sprint Report: IPFS in Web Browsers
What We Achieved
Our stated goal for the 2-week sprint (in the original comment) was:
In short, we made good technical progress, we did line up a lot of the tech and clarify a bunch of tough sticking points. However, we found that
At the end of the 2 week sprint we had @whyrusleeping’s web extension that has the new features of
@victorbjelkholm also made a new web extension that includes the full js-ipfs implementation, runs that as a local node in the browser, and attempts to make the full js-ipfs api available to js running in the browser.
These are in addition to the two pre-existing browser extensions that are NOT web extensions but have fuller UX than the ones we produced.
Basically we need to merge all 4 of those extensions into one web extension with clean, clear UX. After that we need to unify it with whatever work comes out of the ipfs-download.js discussions.
The 4 Browser Extensions
Main Issues we Closed
The Baseline for Browser Integration Milestone spells out the remaining work.
Also see the ROADMAP for IPFS in Web Browsers
Some specific action Items:
I think i have an idea that was not captured here that should solve the problem.
This is similar to the challenge faced by MetaMask to expose Ethereum support to applications.
I'm assembling a proposal I'm calling Client-side Services to generalize the ethereum-specific PoC we've built. https://gist.github.com/kumavis/f8d1b92efe38c3522067f2b34b0a7bd1