IPFS-driven equivalent of google drive?

Hi!

I keep needing it- I’d love an IPFS-driven version of Google Drive, just very simple cloud storage setup.

Ideally just spin it up on any old host- cheap DO drop, aws, free-tier Heroku even- and you can just real easily drop stuff in folders, navigate graphically (viewing “names” of folders/files rather than hashes), etc of the IPFS files on that server? Would make sense for it to be a gateway as well.

Ideally Ideally it’d allow for “sharing” files and folders with other ppl(local accts or diff server accts) with varying permissions for adding or ‘removing’/‘modifying’ stuff in the folder?

Give it a simple-enough API (upload file to given directory via HTTP and return hash, pin/unpin given hash, get file hashes in dir, etc) and i’d use the shit out of it, tbh, for research & journaling & task tracking & memes.

I’m guessing this exists already, cause it seems like really low hanging fruit?

4 Likes

I completely agree that this should exist but, unfortunately, there’s at least one tricky issues that need to be solved first: private data.

Currently, everything added to IPFS is public and implementing an ACL system is non-trivial. We do have private networks but nodes can only be a member of one network (private or public) at a time. You could just encrypt your data but you’d still end up revealing a lot about the files you’re storing (directory structure, file sizes, etc.) unless you store all your data as one big blob (at which point you might as well not use IPFS).

OT: if you would like an existing, working peer-to-peer file syncing tool, I’d recommend syncthing for now.

1 Like

If you upload a folder to IPFS, you can browse it via the gateway like any other folder. Navigate to ipfs.io/ipfs/Qm... or localhost:8080/ipfs/Qm... in your browser, where Qm... is the folder hash.

Private folders are like @stebalien said not implemented.

You could use IPNS to update the folder if you’re okay with making it public. Use ipfs object patch add-link to add a file, and ipfs object patch rm-link to remove a file.

If you want multiple people to add and remove to the same folder, you can copy the key to them. Anyone with the key can then use the aforemented commands to update the folder. If you want to use a server to keep the contents of the latest version pinned, run the command ipfs pin add /ipns/YOUR_KEY periodically, for example with a cron job.

In the meantime, while we wait for private content (encryption), Partyshare (https://partysha.re) is a good example of a tool for adding and sharing directories of files over IPFS. It’s more dropbox-style rather than google drive, but gets the idea across.

1 Like

Partyshare is just a wrapper around js-ipfs. I would recommend ipfs-go instead, it has better performance.
EDIT: and multiplatform support

My initial idea was to put an encrypted filesystem on the IPFS, e.g. using a macOS sparsebundle; example here:

http://ipfs.io/ipfs/QmcQwxQQaSXcxnUnpyXqBP7fD5WqAoDgPSuEgi3Thu5Koa

(You could surely also do this with CryFS et al.)

❯ ipfs ls QmcQwxQQaSXcxnUnpyXqBP7fD5WqAoDgPSuEgi3Thu5Koa
Qmczcs1pEiR8hu1HPyxQYx9UH8NFskKrKCwj4riEVNue5v 508       Info.bckup
Qmczcs1pEiR8hu1HPyxQYx9UH8NFskKrKCwj4riEVNue5v 508       Info.plist
QmdyMovTiW5jF9BLwoGp3ZDKCAG9RHcforsbnmzqpbBAkJ 127957502 bands/
QmXqW4yqgspsrpSV37BVQBJNmhraqnxJREunp5cLRNQKhN 122382    token

❯ ipfs ls QmcQwxQQaSXcxnUnpyXqBP7fD5WqAoDgPSuEgi3Thu5Koa/bands
QmVB3oczLiuPmeSUhuAzJm1pPdYKU9p2pwoz1HqwRKhznu 8390602 0
QmYv97tRqFtvykJTVejqFQ6CjbhXBTk6A498LY4rjH9p1y 2097657 1
Qmc6Wzgo5wKf4LgXPFv7r58YFXvf27W6bLrMSBjwgHBiSb 8390602 143
QmRqMnG62WXjYMSsWU1bG7ibSE5atPsbn5Mv7zgTnJW5y7 8390602 144
QmPDDtNDs75ebFwirLp9H7kvaRhm3ic7D1QtEhRtRH1stn 8390602 19
QmPvGxQc4XYKTS67QHARTsLQfkcM14bY3Amy82b1PMPmPh 8390602 1a
QmRqMnG62WXjYMSsWU1bG7ibSE5atPsbn5Mv7zgTnJW5y7 8390602 1b
QmZCJWUu9wseHLj2tykrh2LAxb8D9QuwxvNP19iVN2266E 6292953 1c
QmS2eCmDiEEBFjqTeBu5f5qgWUBpyEz8zuTCJbWMEzb36D 8390602 25
QmZCJWUu9wseHLj2tykrh2LAxb8D9QuwxvNP19iVN2266E 6292953 26
QmPjfTqLU9w1cQKsyCf6uzspWBrF4VKhAVxm4AaeMC6EYu 8390602 26e
QmXLsv6CND3ZR51hJhK2NeriWp72ffDKmC4z2YZHP4QV8Y 8390602 26f
QmRqMnG62WXjYMSsWU1bG7ibSE5atPsbn5Mv7zgTnJW5y7 8390602 270
Qmc6Wzgo5wKf4LgXPFv7r58YFXvf27W6bLrMSBjwgHBiSb 8390602 27e
Qmdn9BWeo1Gbte4t3sEvYQru2wzxa8d2Vbpd8VMAyFB4QL 8390602 27f
QmUc5MpkFKU4oijWAwKYDJrZqNkbHzLoqKCWqv2fm9JLSe 8390602 38
QmTomRBoPiPmtUBC8jJ4zNxmjb3FPKu8CBRrfJ8RcpxeJp 4195305 39

This specific one is encrypted with the password “123”, and optionally with an S/MIME public key. But the problem is that you can’t cat directories with IPFS. With a DMG it would be easy, just ipfs cat and pipe to open with macOS DiskImageMounter. A sparsebundle you have to download with ipfs get, and then mount it normally, e.g. in macOS Finder.

Private IPFS directories should have, at least in my opinion, some of the features of sparsebundles, CryFS volumes etc., e.g. password protection as a minimum, optional encryption using a public-private key scheme, preferably S/MIME keys, so you can invite the sender of an S/MIME-signed email you’ve received to an encrypted IPFS “volume” that you can generate & secure using your own and his S/MIME certificate. It should also account for editing, adding or removing content, i.e. if the “bands” (encrypted blocks) change, the whole “IPFS volume” is updated.

But in addition to all the encryption functionality, this would also need a big update for ipfs, so that ipfs can “cat” encrypted directories, and somehow mount them, maybe outside of the IPFS as an attached volume, but definitely as references to the decrypted content in a temporary ipfs files entry.

(My 2¢.)

1 Like

You can mount IPFS directories using ipfs mount, that’s good enough to use as source directory for cryfs or sparse bundles. You can either use it in this streaming manner, writing some wrapper that intelligently calls ipfs object patch, or just save - mount - do your business - upload. Unless you have huge directories or large amounts of concurrent users with edit access, the latter works just fine. I don’t see the purpose of adding this into IPFS.

If you mount ipfs/ipns, the system (fuse) just mounts the directory with the cryfs or sparsebundle metadata plus the encrypted blocks. It doesn’t decrypt anything; you still have to run other commands on those directories to achieve that. My idea was that, if IPFS is to implement file encryption one day, why not go a step further and have encrypted volume capability built in, asymmetrical encryption etc., and some form of a “cat & mount encrypted” command. Mounting the whole IPFS datastore with fuse is not necessary, and pretty coarse, too, since you just want to access specific (encrypted) content, and you might even want to stay within the IPFS environment, and work with your decrypted content there. At the end, it’s called the Interplanetary file system, so encrypted FS functionality should at least be addressed.

Correct. Why reinvent the wheel?

As far as I know, only convergent encryption is planned.

Again, why reinvent the wheel? You don’t need to change the protocol for it to work, and bundling tons of “useful applications” in go-ipfs is a fast track to bloat. It would be better handled with a separate program, since a lot of the stuff you’d have to add (GUI, permissions, key distribution) isn’t reusable.

You only access the parts you need. It’s more like the local HTTP gateway than mounting the datastore, I don’t think you can do ls /ipfs/ and get all the hashes available for example.

Use overlayfs to mount /ipfs/YOUR_KEY + /uncommited_overlay to some folder, then use that as source directory for your file system. You then periodically reupload it to IPFS. Or am I missing something, do you want to upload decrypted content to IPFS?

Why? go-ipfs is already 16mb making it unsuitable for some use cases, why do you want to add even more applications that are only useful for end users in there? It’s an interesting application to have on top of IPFS, but there’s no point in integrating it in it.

This same thread is happening over at Use like google drive

Hi!

Things got pretty side tracked here- I was assuming the content is public to view and that’s ok by me as long as it’s communicated well to the user.

The things I actually care about doing are exclusively what is listed in the original post.

“Sharing” a file was only intended as “sending them the hash by whatever format requested, REST API or whatever, for them to pin themselves if they choose.”

This configuration only allows local “edits” just due to using ipns on the server you deployed.

The actual important parts of the ask is the graphical interface with human-readable names of directories or files, the drag and drop interface for file uploading, and the ease of deployment.

Ideally it would include a raw text editor suitable for modifying markdown which would also be drawn from ipfs’ and which would “autosave” by just re-publishing the file on ipns.

1 Like