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.

[lidel]

👀

[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

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