Help me with Lumpy: KISS Desktop interface for IPFS

Hello there!
I started few months ago Lumpy, ideally to build a KISS and Easy to use Desktop interface for IPFS… and I think a lot can be done to improve the user experience (meanwhile somebody else focus on the actual core of IPFS :slight_smile: ). I had less and less time to work on it, but I am planning to help back the community and share something.

Still under development, it requires ipfs installed and configured already, but soon I want to switch to js-ipfs to improve the experience. The main idea is to help people to share files with a simple interface, by using IPFS instead and a Desktop app, instead of something more complex (ex: web app or CLI). So my grandma can do send me a hash :slight_smile:

A lot has to be done, check the Trello board if you want to help!
Trello Board here: Trello
Source here:


Will this only be a GUI client for the node, or do you plan to turn this into a full IPFS file manager and browser? (It would be great to be able to actually browse the IPFS, not only locally, as with a traditional file manager or FTP client etc., i.e. look at a remote object and its subdirectories, and e.g. download (“get” or “pin”) only the file(s) you need, not the whole thing.

As a node client, I could envision a couple of things:

(1) You might want to add an option to encrypt files or whole folders, until encryption has been built into ipfs as a default. (Which kind of encryption? I’m a sucker for asymmetric certificate-based encryption, so openssl & S/MIME public/private keypairs might be a good choice.)

(2) People might also like adding file information (metadata). I know, if you’ve added files to the IPFS using the command line, then you only have hash & size, but you could add filename, file type, optional checksum calculations, local FS timestamps (Unix: created, changed, modified, accessed) etc. for files that are added using the GUI client; you would need a local database, though, where IPFS hashes are linked to this metadata. If this is an option, you could add additional columns to the Storage window, and maybe even an “Edit” button to edit metadata, add file comments, tag files for quick search etc.

Lots of possibilities, actually. Lots of file managers out there to inspire. :slight_smile:

1 Like

The idea is to develop it based on the community needs. I felt some needs that are already described in the Readme file (check also the backlog on Waffle or Trello). It will not replace the Filesystem explorer/File manager on the OS, but it may in the future mount “volumes”. For now I am just focusing on a client for basic interaction and grow from there. The main goal now is to write tests and move from go-ipfs to js-ipfs (with WebRTC support, as the app is built in React on Electrum).

  1. yes, it was in the backlog on waffle, but I want the main IPFS protocol to develop better encryption, and then implement it in the client (following standard probably is better than do things on my own).

  2. YES! YES YES! :smiley: This is the main point, if you check the backlog (on waffle or Trello) you will see that this is a main point ( I think it is also explained in the readme file ).

I couldn’t yet download it; the ipfs get doesn’t respond. Or do you mean the readme on github?

By the way: you’ll eventually have a built-in js-ipfs node, right? Will this in-app node stay disabled, if the user has a standard go-ipfs node running locally system-wide?

1 Like

(I mean the readme on github for Lumpy)

I think it is better that, once switched to js-ipfs, it will set up its own repository… at the moment Lumpy starts the IPFS daemon if not running and connects via API. You can already point the API configuration to a different IP, and ideally we can set up it to point to js-ipfs or go-ipfs locally.

1 Like

I’m trying to pin the current Lumpy version to my node with ipfs pin add -r QmUkPucZ1WUxwGqR979YAKj2UfUsqpSze6MPDcmhtbzmst, but the network isn’t responding, i.e. it doesn’t seem to be available.

My RPI was down this week, sorry! Should be back up now :slight_smile:

Didn’t work either, but I’ve downloaded the files manually via “legacy web”, added them to my local node, and currently caching them on some gateway nodes. Don’t know why it didn’t work; one error was regarding the .sig file: ERROR core/serve: ipfs resolve -r /ipfs/QmUkPucZ1WUxwGqR979YAKj2UfUsqpSze6MPDcmhtbzmst/ Failed to get block for QmZ5Ur118ngKGc4ANzVaK5qqzh8nT93d5SvSuosKQCVszo: context deadline exceeded gateway_handler.go:548 … not an uncommon error with ipfs pin add, it seems, judging from one or two issues on GitHub.

I was able to download it from:

Yup, I had already cached it there. :wink:

1 Like