Started as a discussion between @lidel & @olizilla (2018-12-19)
Granting access to local or remote node remains a challenge both on UX and security fronts.
This is an attempt to plot possible paths for going forward.
Disclaimer: below is not a roadmap, but a "what if" exercise to acts as a starting point for discussion and experimentation that follows in comments
Initial idea is to think about the problem in three stages:
Stage 1: window.ipfs.enable(opts)
ETA: ~Q1 2019
[x] postMessage-based IPFS API Proxy exposed under window.ipfs by ipfs-companion
[ ] Replaced intrusive popup-based UX with OAUTH-like permission flow
[ ] Request for non-sandboxed version of API displays more prominent warning
Stage 2A: Opaque Access Point with Service Worker
[Ongoing research]
ETA: 2019+
[ ] Thin static HTML+JS is loaded to establish Access Point Service Worker (APSW), which acts as a proxy to IPFS API provider and exposes limited API/Gateway endpoints
[ ] Progressive peer-to-peer Web Applications (PPWA) talk to IPFS over APSW
[ ] APSW automatically picks the best IPFS provider (js-ipfs, remote/local HTTP API, ipfs-companion)
Stage 2B: HTTP/WS /api/v1/ with access controls
Bit speculative - work on /api/v1 did not start yet, we are collecting requirements
ETA: 2019? 2020?
[ ] Websites and apps access API of IPFS Node directly
[ ] Access controls done by IPFS Node itself, CORS are allowed by default (*)
[ ] /api/v1/ can start as an experimental overlay provided by ipfs-desktop
OAUTH-like flow introduced in Stage 1 remains the same
Real-time capabilities are supported over Websockets
[ ] window.ipfs in ipfs-companion implemented as a preconfigured js-ipfs-http-client rather than a proxy
The overhead of postMessage is removed
Access controls removed from ipfs-companion and now done by ipfs daemon itself
Stage 3: Nodes talking to each other over libp2p
This is highly speculative idea with a lot of details to figure out, but the general idea to replace legacy transports (HTTP, Websockets) with libp2p
ETA: 2020+
Prerequisites:
[ ] pubsub is enabled by default and works in browser contexts
Granting access to local or remote node remains a challenge both on UX and security fronts. This is an attempt to plot possible paths for going forward.
Disclaimer: below is not a roadmap, but a "what if" exercise to acts as a starting point for discussion and experimentation that follows in comments
Initial idea is to think about the problem in three stages:
Stage 1: window.ipfs.enable(opts)
postMessage-based IPFS API Proxy exposed underwindow.ipfsby ipfs-companionStage 2A: Opaque Access Point with Service Worker
Stage 2B: HTTP/WS /api/v1/ with access controls
Stage 3: Nodes talking to each other over libp2p
Parking this here for now, would appreciate thoughts in comments below.