Initial Draft of Objectives and Key Results for Q1 of 2018

[lidel]

This PR adds objectives-and-key-results/ directory along with the first document for Q1.
I tried to keep them straight to the point and realistic – let me know how I can improve it.

(@diasdavid, is this what you had in mind?)

[lidel]

cc @alanshaw @olizilla for sanity-check of Brave OKR :)

[olizilla]

This looks good. My only hesitation is we need time from Brave devs to get ipfs-companion into brave as a trusted component, to get access to the browser.protocol.* apis. We also need additional apis ported from electron to muon:

• chrome.protocol.registerBufferProtocol for images/webfonts/videos
• chrome.protocol.registerStreamProtocol for large files

As Brave dev time is outside our control, I'm uneasy about pinning our target to it, but we could simply note that concern, and do what we can. We could dig into electron and submit PRs for enabling the apis we need ourselves of course.

[lidel]

Ok, I moved my draft to 'OKR Proposals' section.
This enables us to merge this and let others to PR against it, as suggested in #65

@diasdavid Y/n ?

[daviddias]

Thanks @lidel :)

[victorb]

No mention of exposing window.ipfs? :(

[olizilla]

doc is a WIP, we'll be adding more to it!

[lidel]

@victorbjelkholm feel free to add it in a new PR :)
We are already tracking this effort in ipfs/ipfs-companion#330, I feel it could be shipped as an experiment in Q1 (worse case scenario Q2 if there are big roadblocks). But we definitely started working on it (eg. @alanshaw's https://github.com/tableflip/ipfs-postmsg-proxy)

[victorb]

Thanks @olizilla and @lidel :) Seen all the awesome work, especially ipfs-postmsg-proxy which seems great so far. Was just wary that it was not mentioned in the document.

[alanshaw]

Some news today: