Reframe the OKRs doc. 2018 Q1 #73
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,49 +1,64 @@ | ||
| # IPFS in web browsers: Objectives and Key Results - Q1 2018 | ||
|
|
||
|
|
||
| **WORK IN PROGRESS. This document will change.** | ||
|
|
||
|
|
||
| ## Understand how IPFS _should work_ in web browsers | ||
|
|
||
| _Focus on people. What are the user journeys; what are their goals. How will IPFS improve a web users day?_ | ||
|
|
||
| ### Key results | ||
|
|
||
| - Create **the** reference document for what users goals are when using IPFS as part of their daily web browsing. | ||
| - Document user journeys that capture an ideal UX for achieving those goals. | ||
| - Document how dat and beaker are being used for this today. | ||
| - Start a regular distributed web meetup in London. | ||
|
|
||
| ## Get people excited about using IPFS in the browser | ||
|
|
||
| _Demonstrate what is possible with IPFS in the browser already, and improve the onboarding process._ | ||
|
|
||
| ### Key results | ||
| **[IPFS Companion](https://github.com/ipfs/ipfs-companion) is the reference implementation of IPFS in the browser** | ||
| - Simplified and improved UX ([ipfs-companion/#324](https://github.com/ipfs-shipyard/ipfs-companion/issues/324) [ipfs-companion/#342](https://github.com/ipfs/ipfs-companion/issues/342)) | ||
| - Welcoming, up-to-date developer documentation exists | ||
| - Retain positive presence in browser extension stores | ||
| - Robust CI/QA practices are established, improve test coverage ([ipfs-companion/#145](https://github.com/ipfs/ipfs-companion/issues/145)) | ||
| - Detect [IPFS Desktop](https://github.com/ipfs-shipyard/ipfs-desktop) and provide additional controls ([ipfs-companion/#350](https://github.com/ipfs-shipyard/ipfs-companion/issues/350)) | ||
| - Embedded `js-ipfs` node used when a system ipfs daemon is not availble. | ||
| - IPFS is embeded into every browser page through `window.ipfs` ([ipfs-compaion/#330](https://github.com/ipfs-shipyard/ipfs-companion/issues/330)) | ||
| - Opt-in or access controls exist to prevent web pages from performing actions without prior user approval | ||
| - `window.ipfs` is a proxy over `window.postMessage` to communicate with a running IPFS node exposed by the extension ([ipfs-postmsg-proxy](https://github.com/tableflip/ipfs-postmsg-proxy)) | ||
| - Update PeerPad to use the `window.ipfs` if it is available | ||
| - Provide a step by step guide for devs to create apps that use `window.ipfs`, using PeerPad as the example. | ||
|
|
||
| **Get the [Brave](https://brave.com) integration released** | ||
|
|
||
| - IPFS companion working out-of-the-box in Brave | ||
| - Support for `ipfs://` and `dweb:/ipfs` address schemes in Location Bar and DOM elements (`href`, `src`) | ||
|
|
||
| **IPFS Desktop replaces go-ipfs as the recommended starting point for new users** | ||
|
There was a problem hiding this comment. Note to self: This KR felt out of place but then I realized we can't have great user experience in Firefox and Chrome without IPFS Desktop. It is the prerequisite. I am not sure if we should include sub-items, but that can be decided later, after we move to spreadsheet. There was a problem hiding this comment. There will always be users for whom go-ipfs is the recommended starting point. Need to get clear about which users you're talking about. Also -- is this the right objective for Q1? Why? There was a problem hiding this comment. My assumption here is commandline savvy users won't have much trouble finding go-ipfs, and I'm assuming IPFS Desktop will install go-ipfs as well... which should be expressed somewhere. Right now, ipfs-companion is more complicated to get going with, as we have to ask the user to then install and run go-ipfs separately (non-withstanding the inclusion of js-ipfs, which is a parallel effort). I'd like IPFS Desktop to be front and center on ipfs.io, and have it streamline the user journey, as it'll be able to make the bed for IPFS companion, providing the external daemon, and a mechanism (possibly a For me this fits into the objective of making people excited about using ipfs, as a multi step and commandline based first intro could be off putting to many. I think it'd be valuable work, but I'd appreciate your thoughts on whether this is the right objective for Q1. There was a problem hiding this comment. @flyingzumwalt what if we reword this along these lines: "Improve onboarding experience for casual users by defaulting to IPFS Desktop as the starting point"? (I think what we have in mind by that is something similar to https://www.torproject.org, where after clicking on "Download Tor" you get Tor Browser as the default choice, but you can still click "View All Downloads" and get the raw Tor daemon.) There was a problem hiding this comment. You could go even simpler - "Improve onboarding experience for casual users" and then let the KRs spell out how you intend to achieve that. |
||
|
|
||
| - TBC (what are the plans for ipfs-desktop ?) | ||
| - Update _"getting started"_ section of https://ipfs.io | ||
| - `ipfs-dashboard` is built as a reusable replacement for `ipfs-web-ui` | ||
| - Update `ipfs-dashboard` to use `window.ipfs` if available | ||
| - Create a ui-style-guide repo as a guide to the design language of IPFS apps, and share look and feel with `ipfs-companion`, `ipfs-desktop` and `ipfs-dashboard` | ||
| - A logo for dashboard, desktop and companion to give each an identity that shows they separate parts that work together? | ||
|
There was a problem hiding this comment. This is a neat idea 👍 I created ipfs/ipfs-gui#24 to track this. |
||
|
|
||
| ## Understand how IPFS can be integrated into web browsers | ||
|
There was a problem hiding this comment. This sounds bit too similar to the first Objective.. or is it just me? :)
There was a problem hiding this comment. Reword the objective. The KRs don't match the Objective. The KRs are aimed at communicating a call to action, allowing people to track/contribute to this effort, and lobbying for our technical approach -- not about us gaining understanding. Move the Brave KRs under this and then craft an objective that encompasses the real objective that those KRs are working towards. There was a problem hiding this comment. For me
...is the objective. We don't have a coherent understanding of what we want from browser vendors that we can point them at. We have plenty of issues and shopping lists and individuals that could be prodded for the whats and whys, but we don't, as the in-web-browser own that understanding yet. I see it as this working group needing a coherent and shared understanding of that situation as the goal; so we can be the point of contact, and publish whatever reports are needed to keep everyone on the same page. I've not written up an OKR doc before, so again any more thoughts you have on this would be super helpful. There was a problem hiding this comment. If you got to the end of the quarter and all you had achieved was shared understanding that would be nice but it's under-selling what you're actually planning to do. A more accurate objective would be something like "Present a coherent viewpoint as a group/project, based on shared understanding" There was a problem hiding this comment. The objectives should express an aspirational, qualitative end-state that you want to achieve. It should be something that gives meaning and motivation to the KRs, and it should be clearly expressing something that you don't want to forget while in the thick of things throughout the quarter. There was a problem hiding this comment. @lidel @flyingzumwalt thanks that helps... through that lens then, is our real support the browser vendors objective:
or more generally:
This is working on the assumption that browser vendors are generally onboard with the idea already. It's the developers who we need to give the coherent explanation of how to, and that our internal understanding and presentation of these details is more of a thing that comes out of the key results. |
||
|
|
||
| _Support the conversation with browser vendors. We need to make it as easy as possible for them to see where we are at, what's needed and why._ | ||
|
|
||
| ### Key results | ||
|
|
||
| **Set up `arewedistributedyet.com` as a communal call to action.** ([in-web-browsers/#24](https://github.com/ipfs/in-web-browsers/issues/24)) | ||
| - Publish the list of apis needed, with a tests where possible, a short summary on what it would allow, and a list of p2p projects that want it. | ||
|
|
||
| **Create specs for addressing on the Decentralized Web** | ||
|
There was a problem hiding this comment. Start thinking about how you will make this one measurable. It should be worded in a way that it is unambiguous what it means to get 0.6 on this KR or 1.0. There was a problem hiding this comment. There is an outline at https://github.com/ipfs/specs/tree/master/dweb-addressing with a minimum set of items we want to cover as KR. There was a problem hiding this comment. That outline covers ipfs:// and ipns:// URL schemes. As you've heard me comment, ipns:// URLs have a problem with link rot. The really should be deprecated in favor of an ipfs:// URL to an IPLD object which is a snapshot the current IPNS record (at the time of creating the URL) plus the peer ID for lookup up the latest IPNS record (which can fail if the original publisher stops posting updates). Also, the existing ipns:// URL (which is a public key hash) is not secure in the long term since, years later, the private key may be compromised and the URL is untrustworthy. (An ipfs:// URL to an IPNS snapshot does not have this vulnerability.) There was a problem hiding this comment. @jefft0 noted (ipfs/specs#166 (comment) is a better place for this discussion), will get back to it when we start work on dweb addressing spec. 👍 Back to this PR, I think we should keep this OKR short, perhaps just skip protocol names altogether and replace KR with "addressing schemes are documented" + reference to outline doc. There was a problem hiding this comment. just make sure you have some document that defines, at the beginning of the quarter, what the goal is and how you will measure it. ie. if you add 10 more sections to the outline of the dweb-addressing document next month, are you aiming to have the originally outlined sections complete or are you aiming to have a final draft of the full document? Are you aiming to have the document completed, ratified, and merged into ipfs/specs with a corresponding blog post? |
||
| - `dweb:` proposal is documented | ||
| - `ipfs://` (URL-based solution) is documented | ||
| - Ways to support the Content Origin Policy for IPFS links are documented | ||
| - Published at https://github.com/ipfs/specs/tree/master/dweb-addressing | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this makes sense as an Objective because it doesn't tell us why we're doing it. Instead you should treat it as a KR under the objective about integration with browsers (and maybe reword that objective to be broader than just understanding)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was intended to be read as a key result, but as there were so many bullet points, I avoided triple nesting by pulling up the headline key result as a bold sentence.
Can you give me a clue to what you're thinking on that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was just referring to the discussion we're having about line 50
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the Brave integration using ipfs-companion? If so, this KR makes sense where it is, under the ipfs-companion Objective, but if it's a separate effort from ipfs-companion it might make more sense under the Objective that starts at line 50.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah yes, that is not obvious. The Brave integration is ipfs-companion. The interesting extra thing that it provides is allowing us to explicitly handle
ipfs://anddweb:/ipfsstyle addresses in the extension. We only get to do http redirects to an ipfs gateway in the other browsers right now.