Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Embedded JS-IPFS in Brave (experiment) #716

Closed
33 of 52 tasks
lidel opened this issue Apr 22, 2019 · 4 comments
Closed
33 of 52 tasks

Embedded JS-IPFS in Brave (experiment) #716

lidel opened this issue Apr 22, 2019 · 4 comments
Assignees
Labels
area/brave Issues related to Brave Browser area/chromium Issues related to Chromium-based browsers P1 High: Likely tackled by core team if no one steps up

Comments

@lidel
Copy link
Member

lidel commented Apr 22, 2019

This issue tracks remaining work around embedded js-ipfs running in ipfs-companion in Brave with access to chrome.sockets APIs. For more context, see:

High Level Goals

  • Leveling up js-ipfs to match go-ipfs in features relevant to in web browser uses
  • Brave users can use IPFS with Companion alone, without installing go-ipfs or ipfs-desktop
  • IPFS nodes in Brave can discover each other on the same network and exchange data in p2p fashion

Kanban Board

How to opt-in

Stable release of IPFS Companion can be enabled via Brave Settings (chrome://settings/extensions):

2019-09-20--14-43-17

By default, it works like regular ipfs-companion and External node is used by default, assuming user has go-ipfs or IPFS Desktop installed and running.

Brave users can opt-in and try Embedded + chrome.sockets (see /docs/node-types for more details)

2019-09-20--14-44-37

2019-09-20--14-45-06

TODO

🎨 UX

  • UI for changing Gateway port
    • Right now its just raw JSON with js-ipfs config
  • Redirect to embedded Gateway
  • New embedded node type exists (embedded:chromesockets)
  • Companion UI is aware of embedded Gateway (Support chrome.sockets.* APIs #664 (comment))
  • Play nice with go-ipfs and js-ipfs daemons (Support chrome.sockets.* APIs #664 (comment))
    • user can switch between embedded (default in Brave) and external IPFS nodes
    • use custom ports by default
  • Post-install welcome screen enables user to start IPFS with one click
    • Add option to start embedded js-ipfs
    • See if we able to make it useful on Android as well
  • Brave detects URLs from embedded gateway and displays them as ipfs:// and ipns://

🔌 chrome.sockets

  • feature-detection for chrome.sockets (Support chrome.sockets.* APIs #664)
    • the same package should run on Google Chrome and Brave, chrome.sockets should enable additional powers at runtime
  • Brave overrides Manifest on install from Chrome Web Store to add sockets section

🌐 Embedded HTTP Gateway

🕸️ Local Discovery and UDP/TCP Transports

⚡ Performance

@lidel lidel added the area/brave Issues related to Brave Browser label Apr 22, 2019
@lidel lidel added the P1 High: Likely tackled by core team if no one steps up label Apr 22, 2019
@lidel lidel self-assigned this Apr 22, 2019
@lidel lidel pinned this issue Apr 22, 2019
@lidel lidel added the area/chromium Issues related to Chromium-based browsers label Apr 22, 2019
alanshaw pushed a commit to ipfs/js-ipfs that referenced this issue Jul 4, 2019
> Part of an effort to run embedded js-ipfs in Brave 🦁 ipfs/ipfs-companion#716
> Fixes #1918 

This PR will add support for `/ipns/` paths at HTTP Gateway.
Smoke test: [/ipns/tr.wikipedia-on-ipfs.org](http://127.0.0.1:9090/ipns/tr.wikipedia-on-ipfs.org/wiki/Anasayfa.html) (IPNS+DNSLink+HAMT-sharded website)
 
This PR depends on the following merged PRs:

  - Gateway Improvements from #1989
    (after merging #1989 I will rebase this PR, which will remove first two commits)
  - PeerID 
    eg. `/ipns/<PeerId-as-multihash-b58>`
    - requires #2002 to land first
  - `/ipns/<libp2p-key-in-cidv1>` 
    - requires multiformats/js-multicodec#45
  - DNSLink 
    eg. `/ipns/<fqdn>/path/file` like `/ipns/docs.ipfs.io/assets/logo.svg`
    - requires #2002 to land first
  - HAMT shard support 
    eg. `/ipns/tr.wikipedia-on-ipfs.org/wiki/Anasayfa.html` (`wiki` is a sharded directory)
    - requires ipfs/js-ipfs-http-response#22 and ipfs-inactive/js-ipfs-mfs#48  to land first
  - Tests for `/ipns/` 

License: MIT
Signed-off-by: Marcin Rataj <lidel@lidel.org>
alanshaw pushed a commit to ipfs/js-ipfs that referenced this issue Jul 17, 2019
### Summary

This PR fixes filtering, improves interop with go-ipfs and adds missing tests for `pin ls`

### Details

Old version returned indirect pin when `pin ls -t direct <path>` was executed.

This PR also tweaks error handling to match behavior from go-ipfs/js-ipfs-http-client and pass improved interop tests added in ipfs-inactive/interface-js-ipfs-core#375

I've added some inline comments, hope it helps in review.

### Related

- Improved `pin ls` interop tests: ipfs-inactive/interface-js-ipfs-core#375 
  (this PR is not blocked by interop tests, old ones were less strict)
- We need this fix for embedded js-ipfs in Brave 🦁 ipfs/ipfs-companion#716

License: MIT
Signed-off-by: Marcin Rataj <lidel@lidel.org>
@warren-bank
Copy link

What are the implications and strategy to deal with Google's announcement that Chrome Apps and its APIs (including chrome.sockets.*) are deprecated and will be phased out by the end of 2020?

https://blog.chromium.org/2020/01/moving-forward-from-chrome-apps.html
https://developers.chrome.com/apps/migration

@voidao
Copy link

voidao commented Feb 3, 2020

Hi @lidel @warren-bank , any place(github repository) for trying the progress(source code)? Thanks!

@lidel
Copy link
Member Author

lidel commented Feb 10, 2020

@warren-bank Google's decision end support for "Chrome Apps" in 2022 does not mean immediate removal of chrome.* APIs from the Chromium codebase, and even if that happens, other Chromium-based browsers such as Brave may decide to keep them alive for bit longer, if the maintenance cost is low enough.

Embedded js-ipfs + chrome.sockets* experiment is designed to be a stop-gap until we have native support in Chromium. Depending on how timeline of things like rust-ipfs looks like, we may look into orchestrating go-ipfs similar to what Brave does with Tor binary (before 2022 comes).


@voidao sources are in this repo: code responsible for initializing embedded js-ipfs in Brave is contained within add-on/src/lib/ipfs-client/embedded-chromesockets

@lidel
Copy link
Member Author

lidel commented Jan 20, 2021

Closing this, as we already deprecated this experiment in recent release.
Removal of unused code will be tracked in #967 (comment)

Brave 1.19 shipped with native support for IPFS which leverages go-ipfs instead:

@lidel lidel closed this as completed Jan 20, 2021
@lidel lidel changed the title Embedded JS-IPFS in Brave Embedded JS-IPFS in Brave (experiment) Jan 20, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/brave Issues related to Brave Browser area/chromium Issues related to Chromium-based browsers P1 High: Likely tackled by core team if no one steps up
Projects
None yet
Development

No branches or pull requests

3 participants