Skip to content
This repository has been archived by the owner on Feb 8, 2023. It is now read-only.

Sprint: IPFS in Web Browsers #351

Closed
flyingzumwalt opened this issue Jan 16, 2017 · 18 comments
Closed

Sprint: IPFS in Web Browsers #351

flyingzumwalt opened this issue Jan 16, 2017 · 18 comments
Assignees
@flyingzumwalt @dignifiedquire @daviddias @whyrusleeping @haadcode

Comments

@flyingzumwalt
Copy link
Contributor

flyingzumwalt commented Jan 16, 2017 •
edited
Loading

Main Repository: https://github.com/ipfs/in-web-browsers
Milestone for this Sprint: https://github.com/ipfs/in-web-browsers/milestone/1
Waffle Board: https://waffle.io/ipfs/in-web-browsers

Team for this Sprint

  • flyingzumwalt (pm), diasdavid, haadcode, dignifiedquire, lgierth, victor, whyrusleeping

Top-Level Objectives

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?

Deliverables:
See the objectives section for full details. In a general sense, the deliverables are:

  • Something for browser teams to check out and tinker with while we build the complete case for them to natively support these protocols.
  • Something for application developers to rely on, so they can build compelling applications & demos,

Objectives

To see the open/closed status of these issues, visit the Milestone for this Sprint

  • Document the Effort to Get IPFS into Web Browsers
  • Enable people to install Protocol Handlers in their Browsers
  • Improve Infrastructure as Needed
  • Create Specs for the Protocol Handlers
  • Prepare to make the case for IPFS in Browsers

Objective: Document the Effort to Get IPFS into Web Browsers

Provide Ways for people to understand this effort and Follow the Work

view the cards

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.

view the cards

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.

view the cards

This overlaps with a number of other sprints for this quarter retlated to Seamless Interoperability between js-ipfs and go-ipfs. see #310, #343, #358

Objective: Create Specs for the Protocol Handlers

Document/Specify the APIs, address schemes, security models, etc. necessary for browsers to adopt IPFS

view the cards

Objective: Prepare to make the case for IPFS in Browsers

view the cards

Some of this will be covered in the Delightful Documentation Sprint later this quarter.

Next Steps

For a broader sense of the next steps, see the Roadmap for IPFS in Web Browsers. Our main next step will be:

  • Make the case for IPFS & Decentralized Web Protocols in Web Browsers with Use Cases, Sample Applications and Demos
@jefft0
Copy link

jefft0 commented Jan 24, 2017

Is there an issue for how IPFS bookmarks would be handled in the browser?

@flyingzumwalt flyingzumwalt mentioned this issue Feb 7, 2017
Open
@flyingzumwalt
Copy link
Contributor Author

@jefft0 I've created one here: ipfs/in-web-browsers#21

@jefft0
Copy link

jefft0 commented Feb 7, 2017

Thanks so much! I posted on the issue.

@flyingzumwalt flyingzumwalt changed the title Sprint: IPFS Available in the Browser Sprint: IPFS in Web Browsers Feb 7, 2017
@flyingzumwalt
Copy link
Contributor Author

Ack! I forgot to schedule the Sprint Planning call for the IPFS in Web Browsers sprint. @lgierth @victorbjelkholm @dignifiedquire @daviddias @whyrusleeping @haad can you all do it tomorrow (thursday) at 18 UTC?

@flyingzumwalt
Copy link
Contributor Author

@victorbjelkholm @daviddias @haad @dignifiedquire can you do 21 UTC tomorrow? (@lgierth can't do 18 UTC. @whyrusleeping can't do earlier.)

@flyingzumwalt
Copy link
Contributor Author

To the sprint team (@lgierth @victorbjelkholm @dignifiedquire @daviddias @whyrusleeping @haad @jbenet) I've finished setting up this sprint issue and grooming all of the associated issues for the sprint. Please browse through them before tomorrow's Sprint Planning call.

@daviddias
Copy link
Member

Thank you @flyingzumwalt, it seems to be that this is going to be the best prepared sprint so far! Great job.

@jefft0
Copy link

jefft0 commented Feb 9, 2017

Is this call open to the public (me) to listen in? Will the link be on the public calendar? https://calendar.google.com/calendar/embed?src=ipfs.io_eal36ugu5e75s207gfjcu0ae84@group.calendar.google.com

@flyingzumwalt
Copy link
Contributor Author

@jefft0 I'll try to get it added to the ipfs-community calendar. If you want to listen to the call you can dial into zoom at https://zoom.us/j/731705773 and just turn off your camera. We will also record the call and post the recording.

@kevina
Copy link

kevina commented Feb 10, 2017

Was the recoding ever posted?

@flyingzumwalt
Copy link
Contributor Author

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

Lead: @flyingzumwalt
Notes: @nicola

Strategy

  • First sprint in our effort for IPFS in the Browser
  • We are not ready to natively support IPFS
    • We don't have stories on HOW, WHY
    • We need to clean up IPFS to make this flawless and smooth
    • New mode to push our effort
  • The next two weeks
    • In this sprint we are going to prepare to make the case for IPFS in the browser
    • If we lack stories but we have good tech, we have a great finishing point for the two weeks
  • Key deliverable: Extension in the Browser
  • Diving into Sprint: IPFS in Web Browsers #351
    • Document the effort
      • What is the path of adoption?
      • What is our approach?
    • Improve infrastructure
      • Improving the infrastructure that protocol handlers will rely on
    • Create specs for Browsers
      • Design to be done for protocol handlers
    • Prepare to make the case
      • not necessarely building outcomes

Break time:

  • Q: More about the protocols and the addon?
    • A: The IPFS code is in the addon
    • A: How does the protocol work with JS IPFS running? How should the handler be handled by the extension?
  • Q: Is the protocol handler a blocker?
    • A: No it is not. We need to document what the addon is doing.
  • @david: we need to make sure that we write the extension as if it would be some API that developers should use
  • @juan: don't underestimate the amount of work. Getting the browser to resolve links directly (intercepting JS, etc, etc) is non-trivial
  • @nicola: 1 thing is resolving, 1 thing is using the IPFS API
  • Q: What about just using what we already have for core IPFS for the APIs?
    • A: getting deamon and extension to run
    • A: it means exposing core libraries to instantiate, e.g. .ipfs, .libp2p.
      • Polyfill approach: Injecting a variable into the context?
      • Force users to include some API that will connect to some end-point that is magically there?
    • A: Make the extension that put js-ipfs there
      • This would make ipfs very real
      • Ethereum people have been doing this during the week
  • Q @nicola: is having a .ipfs,.libp2p really practical?
    • in the long term it might be

Moving into the issues

Objective 1

  • Matt going through the different issues

Objective 2

  • Enable people to install Protocol Handlers in their browser
    • Q: need to split Sprint J #11 into multiple cards?
      • A: David gives a list of things that Matt is adding
    • @Lars: Protocol handlers != IPFS API in the browser
    • Create some sort of system
    • @friedel: We need to find out what is the best objective
    • @matt: We want to discuss how to achieve that goal
      • Matt will create an issue for future discussions on this
    • @juan: Resolve the handler in the browser has most priority
    • @juan: Explore what implementation to use!

Objective 2

  • Refine to make this work flawlessly (see issues)
  • Current behaviour of gateway is not aligned with what a browser would expect
  • Getting everyon up to speed the team on IPLD
    • A lot of changes in IPLD space - explain the 3rd generation of IPLD
    • How the resolving work, etc. (?)
    • @juan: it is mostly about how CID works

Objective 3

  • Mozilla implements not URI but WHATWG which is based on location
  • Mainly involves Gozala & Juan, it is important to keep this from becoming a 6 months conversation
  • Suborigin spec, we know the authors

Objective 4

  • Capturing the information crafting the list and narrative
  • Are we going to aim to build any of this?
    • Not sure, we need to identify what these demos are so that anyone in the community can pick up these use cases
      • e.g. IIIF
  • URL rewriting - what URL can be rewritten
  • @nicola to write down multihash and subresource integrity

Summary

  • Write down issues of what we have been discussing that is not listed here
  • Try to estimate if the work is going to be really hard or not - it must be clear what the work is or break it into multiple things
  • @matt I use needs-clarification label if needs conversations
  • @juan: Friedel & others need to figure out knowledge requirements on go/js ipfs since they will be busy in the next sprint (?) - plan resource allocations

@flyingzumwalt
Copy link
Contributor Author

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.

Done:

In Progress:

Upcoming work:

@flyingzumwalt
Copy link
Contributor Author

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

@flyingzumwalt
Copy link
Contributor Author

No standup calls Thursday or Friday (schedule conflicts). @haad @lgierth @whyrusleeping please post a comment with info about what you're planning to work on between now and Monday's all-hands call. If you need help figuring out what to work on, let me know.

@jefft0
Copy link

jefft0 commented Feb 17, 2017

I can help do some testing this weekend (if some code is ready). I have virtual machines for various Mac, Ubuntu and Windows operating systems. I could even try some systems debugging if I didn't have to distract you with too many questions.

@flyingzumwalt
Copy link
Contributor Author

@whyrusleeping is anything ready for @jefft0 to test?

@flyingzumwalt flyingzumwalt mentioned this issue Mar 3, 2017
Closed
@flyingzumwalt
Copy link
Contributor Author

Sprint Report: IPFS in Web Browsers

What We Achieved

Our stated goal for the 2-week sprint (in the original comment) was:

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.

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

  1. This effort needs more concerted attention than we allocated for it in Q1 -- two weeks was not enough. Two more weeks would have made a big difference.
  2. We need a clearer product vision for the browser extension.

At the end of the 2 week sprint we had @whyrusleeping’s web extension that has the new features of

  • Includes an install script that installs ipfs for you (but this has to be done out of band for browser security reasons. UX is not good)
  • Able to start & stop the local go-ipfs daemon

@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.

Relevant Code

The 4 Browser Extensions

Repository Author Extension Type Features
https://github.com/lidel/ipfs-firefox-addon @lidel Firefox addon redirects gateway urls. Shows ipfs node controls & info on the IPFS icon in browser menu bar. Includes a lot of work on URL rewriting.
https://github.com/fbaiodias/ipfs-chrome-station @fbaiodias Chrome extension redirects gateway urls. Includes variant of ipfs-station UI in browser menu bar Has the nicest UI.
https://github.com/whyrusleeping/ipfs-webext @whyrusleeping web extension redirects gateway urls. Includes script to install go-ipfs daemon. Able to start/stop daemon from browser
https://github.com/VictorBjelkholm/js-ipfs-in-the-browser @victorbjelkholm web extension redirects gateway urls. Attempts to make the full js-ipfs api available in the browser

Main Issues we Closed

Next Steps

The Baseline for Browser Integration Milestone spells out the remaining work.

Also see the ROADMAP for IPFS in Web Browsers

Some specific action Items:

Acknowledgements

Special thanks to @lidel, @Gozala and @jefft0 for helping out on this sprint, and apologies for the long delay on publishing this sprint report.

@kumavis
Copy link

kumavis commented Apr 17, 2017

I think i have an idea that was not captured here that should solve the problem.

IPFS is usable by web applications without bundling IPFS into those applications and without running a separate IPFS daemon on their users' machines?

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

@ghost ghost unassigned victorb Jun 22, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@flyingzumwalt flyingzumwalt

@dignifiedquire dignifiedquire

@daviddias daviddias

@whyrusleeping whyrusleeping

@haadcode haadcode

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
9 participants
@flyingzumwalt @victorb @dignifiedquire @daviddias @whyrusleeping @kevina @kumavis @jefft0 @haadcode