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?
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.
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.
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.
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.
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.
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.