v2.2.0
Summary
This is v2.2.0. Long time due, but finally we are here! 🎉
Installation
- Firefox: Install from Mozilla Add-ons
- Chrome: Install from Chrome Web Store
- Other: use
*generic.zip
above or build and install it manually
Release Highlights ✨
IPFS API exposed as window.ipfs
IPFS Companion is exposing a subset of IPFS APIs as window.ipfs
on every webpage ✨
This means websites can detect that window.ipfs
already exists and use it instead of spawning own js-ipfs
node, which saves resources, battery etc.
Make sure to read our notes on window.ipfs in v2.2.0.
Additional background and open questions can be found in original issue: Expose IPFS API as window.ipfs (#330)
Some highlights below:
window.ipfs
property in every web page! 🎠- also adds
window.Buffer
if not there - also adds
window.Ipfs
- also adds
- Proxies to running js-ipfs or go-ipfs node (via js-ipfs-api) in the extension
(improves performance and battery life)- in-depth 20min talk: How window.ipfs works in IPFS companion
- Scope-based permissions (origin+path)
- 4min video explanation: window.ipfs scope based permissions
ipfs.files.*
APIs are additionally sandboxed within an application path (#431, FAQ)
- Built-in access controls for proxied IPFS functions (#382)
- Documentation: window.ipfs.md @ v2.2.0
- Demo apps that use
window.ipfs
Embedded Node (js-ipfs)
We now provide a mechanism for switching between embedded and external IPFS nodes.
Embedded node is a fine fallback for situations when user needs to quickly share a file with someone or just wants to run a dapp against window.ipfs
but has no third party IPFS daemon running locally.
User can provide own config (eg. to enable experimental pubsub) via Preferences (#395, visible only when embedded node type is selected)
UX Note: Embedded node does not run when external one is used. Every time you switch to Embedded node, a new instance is spawned on-demand, so it takes a few seconds for a brand new node to find peers:
Other Improvements
Protocol Indicator in Firefox
This feature is limited to Firefox – sorry Chrome users! :-)
Different color and tooltip are shown when resource was loaded via local gateway:
- grey icon – valid IPFS resource, but loaded from a public gateway (via HTTP)
- aqua icon – IPFS resource loaded via user's custom gateway (actual IPFS was used)
Page Actions in Firefox
To make things more intuitive, page-specific actions are available in a short menu under Protocol Indicator:
Support for simplified redirect-based protocol handlers without web+
prefix in Firefox >= 59
Still just a redirect and not a real protocol handler, but it is a step in the right direction.
More info: #164 (comment)
Known Issues
- Support for simplified redirect-based protocol handlers does not work on Android due to upstream bug.
Want help?
- Should we merge virtual roots for the same IPFS Paths on different gateways?
See pros and cons in #330 (comment) - Translate user interface to your preferred language! #300