Move meeting notes from in-web-browsers into team-mgmt

ipfs/in-web-browsers#130

License: MIT
Signed-off-by: Marcin Rataj <lidel@lidel.org>

meeting-notes/2017/2017-03-29--in-web-browsers-standup.md

@@ -0,0 +1,35 @@
+Participants:
+- @diasdavid
+- @JayCarpenter
+- @lgierth
+
+Recording: https://ipfs.io/ipfs/QmYUbamFQLbmHc4WiBr2jhJrZeCtQHN3U59ixW3QCEdBgM
+
+### updates
+
+@lgierth
+- refining relay spec
+- got ssl certs for /ws bootstrappers
+  - TOO bump proxy_read_timeout to 30
+- next: /ws transport on go-ipfs gateway
+- nextnext: configurable announced addresses
+
+@jaycarpenter
+- have been hopping on irc and continuing to get oriented regarding the whole ecosystem
+- not working on a specific item at the moment
+
+@daviddias
+- @dignifiedquire implemented dht module
+- @daviddias implementing dht module integration
+- refining relay spec
+- supporting @drjayov implementing relay
+- debugged /ws bootstrappers with @lgierth
+- js-libp2p-record shipped
+- next: getting dht work finished
+
+### observations
+
+- it's good to have the implementers directly focused on, and involved in, spec work
+- it was also useful to have a baseline with the general approach direction already in place
+  - because it was already a month or two old, there was time to let it sink in
+  - this allowed for very focused and productive refinement discussions right from the start

meeting-notes/2017/2017-10-02--lab-week-discussions-on-ipfs-in-browser-extension.md

@@ -0,0 +1,137 @@
+# Roadblocks for IPFS in Browser Extension
+
+This memo is a summary of various conversations we had during
+Lab Week for Q4 2017, starting with unconf session on Monday.
+
+> **TL;DR**
+> - Right now, [ipfs-companion](https://github.com/ipfs/ipfs-companion) requires external daemon and _just pretends_ to support `ipfs://`, `dweb:` protocols,
+> - we've identified Three Problems that need to be solved to have IPFS running natively in browser extension,
+> - creation of [Programmable Protocol Handler API](#new-native-programmable-protocol-handler-api-for-webextensions) would solve all of them.
+
+# Identified Problems
+
+## Problem #1: Inability to Inject HTTP Responses by WebExtension
+
+It is possible to run js-ipfs node in extensions background page, but when it
+comes to major players in browser space we are missing WebExtension API that
+"enables the extension to satisfy hijacked HTTP request by injecting response read by js-ipfs".
+
+As of now (2017) [`browser.webRequest`][2] API makes it possible to:
+
+- cancel the request in `onBeforeRequest`, `onBeforeSendHeaders` and `onAuthRequired`
+- redirect the request in `onBeforeRequest`, `onHeadersReceived`
+- modify request headers in `onBeforeSendHeaders`
+- modify response headers in `onHeadersReceived`
+- supply authentication credentials in `onAuthRequired`
+
+What is missing are means of providing response payload instead of redirection
+in `onBeforeRequest` step of request life cycle.
+
+
+## Problem #2: Inability to Control How Origin Is Calculated
+
+Web security model relies on [Same-origin policy][3].
+
+This introduces two major inconveniences for websites loaded via IPFS2HTTP gateways (serving content from `/ipfs/` and `/ipns/` paths):
+
+- every IPFS gateway has different Origin, making it impossible for a user to persist state while switching gateways
+- an Origin of a single gateway is shared by all sites loaded from it, making it impossible to write secure web apps
+
+Some people solve this by creating artificial subdomains that have URL-safe CID
+in them (`$cid.ipfs.dweb.link`). A subdomain provides separate Origin and
+creates an isolated security context.
+
+Unfortunately, this is not possible for a gateway running on `127.0.0.1`.
+
+
+## Problem #3: Inability to Control Address in Location Bar
+
+This is a major UX issue.
+
+We should  have:
+
+```
+dweb:/ipfs/QmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR
+```
+
+instead of:
+
+```
+http://127.0.0.1:8080/ipfs/QmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR
+```
+
+
+# Possible Solutions
+
+## Temporary Hacks and Partial Workarounds
+
+[Problem #1](#problem-1-inability-to-inject-http-responses-by-webextension) might be (partially) solved with:
+
+### Creative Use of Service Worker
+
+We could have js-ipfs running inside of a Service Worker acting as a 'proxy'
+for  HTTP requests to the public gateway.
+
+See demo and PoC at [IPFS runs as a Service Worker][6].
+
+  - Good:
+    - service worker can inject responses for a host it was installed from
+    - if we provide Service Worker for the public gateway, and browser
+      extension redirects everything to public gateway, then we are able to handle all IPFS requests
+    - transparent for the end user
+  - Bad
+    - a user needs to visit regular HTTP site to install Service Worker
+        - Really bad: [service worker must be refreshed/downloaded every 24h][7]
+    - if we want to solve [#2](#problem-2-inability-to-control-how-origin-is-calculated) we need to have separate service worker for every gateway/root CID
+    - no connection closing + global Service Worker = memory leaks
+    - does not address [#3](#problem-3-inability-to-control-address-in-location-bar)
+
+### Extending `webRequest` API to Support Response Injection
+
+In theory, extending existing `browser.webRequest` APIs to support response
+generation (e.g. from within `onBeforeRequest` hook) would enable us to hijack
+requests and respond with data read via js-ipfs.
+
+There is a very low probability that such API change will happen, these APIs were designed this way with certain security constraints in mind.
+
+Even if it would happen, it would not address problems [#2](#problem-2-inability-to-control-how-origin-is-calculated) and [#3](#problem-3-inability-to-control-address-in-location-bar).
+
+## New, Native, Programmable Protocol Handler API for WebExtensions
+
+What we really need is a new WebExtension API that lets us define a programmable protocol
+handler.
+
+Such API should enable browser extension to do three things:
+
+1. Respond to `dweb:` requests with actual payload (no redirect to HTTP).
+
+   To be more specific, WebExtension should be able to provide function that
+   takes a URI and returns `new Response(data, headers)`
+
+2. Control how _Origin_ is calculated.
+
+   In case of `/ipfs/$cid`, every CID would have its own Origin.
+
+3. Display and support use of `dweb:` address in GUI (location bar, bookmarks, etc)
+
+   This would not only improve user experience but also enable us to use `dweb:` links by default.
+
+The good news is that creation of such API was already proposed in [Bug 1271553: Add ability to implement programmable custom protocol handler][4].
+
+The bad news is that it won't happen this year, as most of the engineering efforts at Mozilla are focused on [Firefox Quantum][5] release.
+
+Still, this is the best way to solve our Three Problems.
+
+We should advocate creation of such API, as it would not only enable us to do
+great things with IPFS browser extension, but could enable Firefox to become an
+application platform.
+
+
+[1]: https://github.com/ipfs/js-ipfs
+[2]: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/WebRequest
+[3]: https://en.wikipedia.org/wiki/Same-origin_policy
+[4]: https://bugzilla.mozilla.org/show_bug.cgi?id=1271553
+[5]: https://www.mozilla.org/en-US/firefox/quantum/
+[6]: https://github.com/ipfs/in-web-browsers/issues/55
+[7]: https://github.com/w3c/ServiceWorker/issues/514
+

meeting-notes/2017/2017-12-29--in-web-browsers-q1-planning-brainstorming.md

@@ -0,0 +1,91 @@
+# IPFS in Web Browsers Q1 Planning/Brainstorming (I)
+
+## Attendees
+
+- @diasdavid
+- @olizilla
+- @lidel
+- @dmitriy
+- @kyledrake
+- @flyingzumwalt
+
+# Agenda
+- Overview
+- Forming the working group
+	- What is the purpose of the WG
+- Checking in with the context
+- Setting OKRs
+
+## Notes
+
+First official meeting of the not yet official IPFS in Web Browsers working group.
+
+### Forming the Working Group
+
+**[Current Working Groups Proposal](https://github.com/ipfs/ipfs/blob/8dc70f4d9676b181734c7818908f422af8fb47f5/WORKING_GROUPS.md#integration-with-web-browsers)**
+
+What is the purpose of the WG? What does the IPFS world think a WG is?
+
+We want it to be clear what the community should expect from a WG.
+
+Some things we're leaving loose or undefined for now:
+- does the WG control a repo?
+- where is their work tracked?
+- Is there a procedure for discussions, decisions, etc?
+
+Some desirable characteristics for WGs
+- If you have KRs for the WG it should be hard to pull you off that.
+- It should be welcoming/inviting for people to join and participate
+- (as specified in the proposal) there should be a captain and a co-captain 
+
+
+### Context (checking in, getting synced)
+
+- lidel's proposed OKRs: https://github.com/ipfs/in-web-browsers/pull/62
+  - these are only for browser extension
+  - a starting point for further discussion
+
+Lots of ideas and conversations already floating around
+- kyle's thoughts about UX
+- address scheme discussions ... [The four stages of the upgrade path for path addressing](https://github.com/ipfs/specs/pull/152#issuecomment-284628862) ... 
+
+Use Cases
+- persistence layer for a dapp developers (Open Bazaar use case)
+- IPFS as filesystem ... nice distributed filesystem
+- IPFS for serving/publishing web pages
+- IPFS the distributed web ... getting 2 billion to use something that works better than HTTP
+
+
+### Setting OKRs
+
+**TASK**: Extract the document that defines the ultimate dream for IPFS in web browsers and expresses what to do in the next 3 months
+- this mainly involves gathering all the info that's floating around out there, putting it in one clear document
+
+Proposal: revisit kyle's "screed" proposal, update that and use it as the defining UX vision.
+- the only part that people have disagreed with is the idea of creating our own browser
+- if we don't build our own browser we will need to set someone up as our lobbyist connecting with the browser manufacturers 
+
+#### Possible KRs
+
+- Understand what is the ideal UX and agree on it (multiple iterations)
+- create a browser demo that shows the browser manufacturers how it _should_ work (some misgivings about whether this is the right way to spend effort)
+	- cost-effective alternative: [Create WebExtensions Experiments to Prototype Missing APIs](https://github.com/ipfs-shipyard/ipfs-companion/issues/343)    
+      ([WebExtension Experiment](https://webextensions-experiments.readthedocs.io/en/latest/)  + demo use in IPFS Companion)
+	- expensive alternative: fork firefox as a demo -- this is how Tor Browser works, and how they propose features within the firefox team 
+- create a "Call to Arms" that tells and shows why this is important and how it should work
+- Establish a style guide for IPFS apps in the browser
+- spring cleaning -- clean up the in-web-browsers repo. update issues, update docs, etc.
+	- make the web-browsers repo into a reliable reference point for anyone interested in this effort 
+
+Straw Poll of Group's Priorities
+- Making IPFS look & work well
+	- are we distributed yet?
+
+# Action Items 
+- submit PRs with OKR proposals ([OKR.md](https://github.com/ipfs/in-web-browsers/blob/master/OKR.md))
+  - everyone declare what they want to work on (pitch your own goal)
+- create a channel in irc 
+- meet again in 10 days (around 8-10 January)
+- spring-cleaning https://github.com/ipfs/in-web-browsers/issues
+
+

meeting-notes/2017/2018-01-09--in-web-browsers-q1-planning-brainstorming.md

@@ -0,0 +1,42 @@
+# 2018-01-09: IPFS in Web Browsers Q1 Planning/Brainstorming (II)
+
+
+## Attendees
+
+- Matt Zumwalt
+- Alan Shaw
+- @olizilla
+- David Dias
+- @lidel
+
+## Agenda
+
+- **Review OKR**
+	- Discussed `OKR.md` draft, fleshed out some action items:
+		- reword _"Embedded js-ipfs runs in Brave without installing external daemon"_ to something like _"Identify and document missing pieces to run a reliable embedded js-ipfs in Brave (without installing external daemon)"_
+		- reword _"Improved initial experience for non-technical users of mainstream browsers"_
+			- focus KRs on Fleshing out user stories/journeys and create UX/style guides
+		- fold "Brave  one" into a KR under "Structure documentation and discussion around the primary Browser vendor concerns"
+    - Everyone will do one more iteration in a single PR
+    - ... then move OKRs to Google Spreadsheet and add assignments and priorities
+- PSA: Started GUI/UX initiative at https://github.com/ipfs-shipyard/pm-ipfs-gui
+	- PSA: Started work on UX/Style Guide: https://github.com/ipfs-shipyard/ipfs-ui-style-guide
+-  Briefly introduce a Person of Interest to new team members :-)
+	- @gozala is a valuable point of contact/discussions for dweb integration with browsers (Beaker etc)
+- Spring cleaning in progress
+- Identified need for coherent documentation of addressing on the dweb
+  - current state of addressing spec: https://github.com/ipfs/specs/tree/addressing/dweb-addressing
+- `arewedistributedyet.com` kick-off
+  - Tracked in [existing epic @ ipfs/in-web-browsers](https://github.com/ipfs/in-web-browsers/issues/24#issuecomment-355942618)
+  - Registered Domain Name: AREWEDISTRIBUTEDYET.COM
+
+## Appendix
+
+### Q:
+- where is the line between functionality that’s only available in node vs func that’s available in browsers?
+
+### A:
+- Anything that's in IPFS-core spec should be available in browsers and in node (Everywhere)
+- tl;dr anything that interfaces with the OS is tricky or different in browsers. mostly: libp2p transport and discovery, and ipfs datastore (and also different between language runtimes, js/go/rust, depending on the availability and quality of libraries)
+- IPFS should be figuring out how to talk to other nodes, but in some cases this doesn't work within the browser. We are working to address those cases.
+

meeting-notes/2018/2018-04-03--gui-and-in-web-browsers-weekly.md

@@ -0,0 +1,35 @@
+# In Web Browsers and GUIs: Weekly IRC Sync (2018-04-03)
+
+Participants:
+- #ipfs-in-web-browsers
+
+## Agenda
+
+- What did you work on last week, what are you working on this week?
+- [Q2 OKRs!](https://github.com/ipfs/in-web-browsers/issues/78)
+  - [Q2 OKR sheet](https://docs.google.com/spreadsheets/d/1xIhKROxFlsY9M9on37D5rkbSsm4YtjRQvG2unHScApA/edit#gid=755202447)
+  - Decisions:
+      - **AI @all**: Add yourself to OKRs as you feel appropriate
+      - **AI @lidel**: ping Matt/David for feedback 
+- GUIs (**AI @ all**)
+  - Share WebUI look'n'feel inspirations
+  - Write up ideal UX definitions
+  - Wireframes
+  - Accessibility testing
+    -  https://github.com/pa11y/pa11y
+    -  Seek advice on how to do well
+        -  Provide feedback and ideas in  https://github.com/ipfs-shipyard/pm-ipfs-gui/issues/28
+  - Tech choices
+    - Review proposal: https://github.com/ipfs-shipyard/pm-ipfs-gui/issues/51
+- In web browsers
+  - Companion release v2.2.0
+    - [try the chrome beta channel](https://chrome.google.com/webstore/detail/ipfs-companion-dev-build/hjoieblefckbooibpepigmacodalfndh)
+    - **AI @ lidel**: write RN and blogpost, QA, release & press "post"
+  - Brave chat (all is chromium now)
+    - https://brave.com/development-plans-for-upcoming-release/
+    - **AI @ lidel, olizilla**
+  - Comms channel for p2p and browser devs
+  - arewedistributedyet
+
+## Action Items
+Marked inline in agenda as **AI**