Local IPFS connectivity

Developers
,
1

Context

A user with a webnative filesystem that contains public and private, encrypted, data. We will refer to this filesystem as just data, because that’s all it is to IPFS.

Setup

  • All the data lives in a S3 bucket, this data is never deleted.
  • The data is available through our IPFS cluster.
  • A js-ipfs instance in a shared web worker, accessed by apps on different domains through an iframe.
  • The js-ipfs instance contains a partial set of the data. Here we pin the data the user is actually using. This data is stored in indexedDB.
  • The user has multiple devices, and thus multiple js-ipfs instances.

Problem

To increase the performance of the system locally, connectivity between devices, and reduce the load on our IPFS cluster, we want to pin the js-ipfs instance data to the user’s local IPFS nodes. I want to emphasise that these local nodes are totally optional, the system works without them. That said, the additional local nodes would greatly benefit the user, because if they’d switch devices, they would get the data much faster (that is, if the second device finds the other one in sufficient time).

Technically speaking, the problem is, how do I directly connect the js-ipfs node with the local node(s). There is no easy way to connect to my local IPFS Desktop node, or Brave’s in-browser node, from js-ipfs.

Solutions

The most straightforward solution I could think of was to:

  1. Enable the WS transport on the local nodes. For the solution to really work, this should be enabled by default. Related issue: Leveraging ws://localhost provided by local IPFS node · Issue #177 · ipfs/in-web-browsers · GitHub
  2. Use a custom libp2p instance with js-ipfs so we can dial to ws addresses in addition to wss.
  3. Attempt connections to various default local addresses. Try connecting with localhost on IPFS Desktop’s default port. Same with Brave, etc.

I imagine there’s various issues with this:

  • Gozala has mentioned that there are security issues regarding the unsecured ws transports.
  • Instead of attempting connections with various addresses, we should be sure there is actually something to connect to before we make the attempt. What if users changed the default ports?
1 Like
2

This is great, thank you.

I think our first goal should be for things to work out of the box for the default use case. This means Brave and IPFS Desktop with default settings. Running a custom local IPFS node (or locally on your network, like on a Raspberry Pi), are stretch goals / next steps (and are probably supported through documentation and custom settings).

4 Likes
3

“This means Brave and IPFS Desktop with default settings”

Yes

At some point I tweeked some of the ports for IPFS desktop because it confilcted with fission CLI.
I would like to have all three working without interference i.e.

  • IPFS Desktop
  • Fission WebNative SDK
  • Fission CLI

Regarding brave, I assume that if I just open every file that is already pinned in indexDb as it is added to the fission drive via its CID in brave via the build in ipfs:// protocol handler those files will be available via the browser’s native IPFS node.

bafkreicshqzf6nbyzrwamv7yyaipyoyfwvb66djrzltszb23t4iq2zcsc4

image
image1153×482

image

4

Investigated further. Started using RemNote that can be used to publish too.
The offshoot of all this is that if I want to share links to public files
in MindDrive powered by Fission WebNative SDK
if I open them in brave via ipfs:// protocl handler on the desktop
these files will be pinned on the IPFS network and an ordinary https link gets generated that like so

https://bafkreicshqzf6nbyzrwamv7yyaipyoyfwvb66djrzltszb23t4iq2zcsc4.ipfs.dweb.link/

5

Hi @gyuri-lajos — this is fetching from Fission servers, not from localhost. This is describing the problem that js-IPFS does not connect to local nodes.

The Fission CLI uses IPFS on custom ports and doesn’t conflict with IPFS Desktop.

6

Hi @boris I know, I just saying what I think would be desirable over all.