Reframe the OKRs doc. 2018 Q1

[olizilla]

Focus on the most urgent high level goals

• We have a shared understanding of 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?
• Understand how IPFS can be integrated into web browsers
• Browser developers understand the requirements of the decentralized web
  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.
• Get people excited about using IPFS in the browser
• Lower the barrier to entry for casual users
  Demonstrate what is possible with IPFS in the browser already, and improve the onboarding process.

and reconsider all the previous items as a means to delivering them.

This needs input on the goals for ipfs-desktop.

[daviddias]

Ready to move to the spreadsheet?

[lidel]

👀

[flyingzumwalt]

still needs some changes.

[flyingzumwalt]

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?

[olizilla]

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 connectNative api binary) to allow IPFS companion to start the system ipfs daemon for the user automagically.

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.

[lidel]

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

[flyingzumwalt]

You could go even simpler - "Improve onboarding experience for casual users" and then let the KRs spell out how you intend to achieve that.

[flyingzumwalt]

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)

[olizilla]

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.

maybe reword that objective to be broader than just understanding

Can you give me a clue to what you're thinking on that?

[flyingzumwalt]

I was just referring to the discussion we're having about line 50

[flyingzumwalt]

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.

[olizilla]

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:// and dweb:/ipfs style addresses in the extension. We only get to do http redirects to an ipfs gateway in the other browsers right now.

[flyingzumwalt]

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.

[olizilla]

For me

Understand how IPFS can be integrated into web browsers

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

[flyingzumwalt]

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"

[lidel]

Great job @olizilla, I feel framing everything around these three objectives made it a much better read 👍

Added some comments, we can address them here or in spreadsheet – up to you.

[lidel]

This sounds bit too similar to the first Objective.. or is it just me? :)
Maybe something like:

• "Create reference materials to support conversation with browser vendors"
• "Create reference materials on how IPFS can be integrated into web browsers"
  ?

[lidel]

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.

[lidel]

This is a neat idea 👍 I created ipfs/ipfs-gui#24 to track this.

[flyingzumwalt]

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.

[olizilla]

@lidel @flyingzumwalt thanks that helps...

through that lens then, is our real support the browser vendors objective:

Browser developers understand the changes needed to enable the ideal IPFS user experience

or more generally:

Browser developers understand the requirements of the decentralised web.

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.

[flyingzumwalt]

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.

[lidel]

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.
(At this point it makes sense to keep it all as a single document, unless it turns out beneficial to split it.)

[jefft0]

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

[lidel]

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

[flyingzumwalt]

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?

[olizilla]

@hacdias do you have any specific goals or ideas you'd like to discuss for IPFS Desktop? Right now I've got a TBC around the details for that in this doc.

[olizilla]

OK(R) friends. Please take a look at https://github.com/ipfs/in-web-browsers/blob/bcbe1993103a0524993cf0d52148ff58cba0f295/OKR.md

OKRs are harder than they first appear! Thanks for all the great feedback. I think this is getting pretty close to what we discussed.

There are some details to work out, but I think it's ready for spreadsheeting. Notably we need to pin down the ideas around the IPFS Desktop installer (can it install command line tools as well?, can it add a connectNative binary for IPFS Companion) and any other key results for it. @hacdias @diasdavid @lidel @flyingzumwalt

[hacdias]

Have automatic releases with Jenkins you be a nice Key result but I think @victorbjelkholm should be the one dictating if this should be a KR or not.

[lidel]

Yes, it is a good KR. To be specific:

• Jenkins job builds installer artifacts for all supported platforms from a specific git tag

I feel we should also add this KR:

• IPFS Desktop installers are signed on MS Windows (Mac?) and do not cause any security warning on user's machine.

This is crucial for good onboarding experience. Thoughts?

[flyingzumwalt]

@olizilla the draft you linked to (https://github.com/ipfs/in-web-browsers/blob/bcbe1993103a0524993cf0d52148ff58cba0f295/OKR.md) looks good to me, with one change:

This KR still needs to be reworded to be more specific -- "new users" is too broad:

IPFS Desktop replaces go-ipfs as the recommended starting point for new users

There are thousands of people for whom the IPFS command line is, and will be, their recommended starting point. Many of those users will never install ipfs-desktop because they want, and have, a unix command line utility that serves their needs. Remember that the cli and the http API address a wide array of use cases that will never be incorporated into ipfs-desktop.

So we need a different wording that acknowledges this.

Alternative wording could be something like

• IPFS Desktop becomes the recommended starting point for non-command-line users
• IPFS Desktop becomes a first-tier option for new users, alongside go-ipfs

etc...

[daviddias]

Hi all!

Are we ready to move the rest of the conversation to the OKR spreadsheet? I understand that there is still some wording to be polished, but I believe we can also do it there.

We need to have the priorities (P0~P4) for each KR assigned and a prediction of how much time each KR will take each one of us so that we don't fall into the trap of planning 1000 hours of work for 240 hours available. We also should have by now owners for each KR.

[lidel]

I think we can merge this and then move it to spreadsheet, finish cosmetic tweaks there, add priorities and assignments.
(Polish from sheet can always be backported to version in this repo in separate PR, after we are done with planning).

[lidel]

I'll move it to IPFS + libp2p 2018 Q1 OKRs: In Web Browsers Sheet later today 👌

[EternityForest]

IMHO, aside from the idle bandwidth issue, dynamic content is one of the biggest things in the way of widespread adoption. I think there needs to be an API to allow any regular old web page to do things like create an IPNS directory (That is private to you, and only accessible by that site and not others, just like JS web storage).

Being able to send direct messages to anyone else's browser on the same site, or to special pubsub addresses. Maybe any page can freely send stuff to any pubsub channel that begins with SomeIPNSRootPrefix/SendersNodeId.

Maybe then can also send to anything starting with SomePubSubChannel/Public.

Maybe messages sent from this API can optionally be signed with the sender's private key, so you know it's from them.

That would let people create blockchain-free Twitter clones in a secure way, only giving the page as much access as is needed.

The JS APIs here are critical I think. Things like managing pinned content (What if 2 sites both want to pin something, how do you count that against their resource limits) are important.

When it's actually easier to develop an IPFS site than a server based site (Which it very well could be), then everyone will want to try it.

[flyingzumwalt]

@EternityForest these are great suggestions. They'll get lost if they stay here on this PR, which is about to be closed. @lidel @olizilla where is the best place for discussing suggestions like these? Issues in this repo? The IPFS forums?

[lidel]

I'd say https://discuss.ipfs.io for general discussion and bouncing ideas off other people in community, and in-web-browsers/issues/new for specific proposals related to web browsers and web dapps.