Feature Request: Image upload uploader

[Schwartz10]

Hey friends!

This is a request for a 3box instance method that takes a file, and a key to save that file to in a user's 3box, and does all the IPFS related things + data formatting.

So for example, say I wanted to save a a new coverPhoto:

const reader = new FileReader()

reader.onload = async () => {
  const file = Buffer.from(reader.result)
  const box = await Box.openBox('0x12345abcde', ethereumProvider)
  await box.public.setImage(file, 'coverPhoto')
  box.onSyncDone(() => {
    const coverPhoto = box.public.get('coverPhoto')
    console.log(coverPhoto)
    /* 
      prints:
      [
        { 
          contentUrl: { "/": "QdzMfdjfkslfj" }, 
          @type: "ImageObject", 
          ... 
        }
      ]
    */
  })
}

You could also provide a custom imageGetter that fetches files too:

  const box = await Box.openBox('0x12345abcde', ethereumProvider)
  await box.public.getImageFile('coverPhoto')
 // would return the actual file buffer

This would be a big, quick win for a couple reasons:

1. Avoids end developers screwing up the data formats for images
2. avoids end developers needing to include ipfs as a dependency in their applications

Let me know your thoughts! :) Or if you want to just bounty it...

[oed]

Interesting, this would indeed be pretty cool. Do you think it should be limited to only images, or do other types of files as well? Might be more difficult do do something general. This is also relevant: https://blog.ipfs.io/89-js-ipfs-0-36/

My main concern with this would be how to pin the file/image. You would have to 1. Supply a http endpoint on which the file is pinned, or 2. the 3box-pinning-node would need to go though your DB and find any file references and pin them. I tend to like option 2 because that also keeps a local copy of the file for the user in case they are offline.

There is also a concern with how encryption would be done on the private-store. Seems doable to figure out though!

[Schwartz10]

Do you think it should be limited to only images, or do other types of files as well?

Oh good point! I feel like it could go either way - images seem to be the most common file type in profiles, but I dont think it would be much more difficult to generalize it.

My main concern with this would be how to pin the file/image

Hmm not sure I totally understand the challenge here, but seems like it's broken into 2 smaller bits: where and how to pin. Where seems relatively simple - you could just use your 3box pinning node or an IPFS cluster (or even infura like 3box-dapp does?). How is what I'm a bit confused on:

would need to go though your DB and find any file references and pin them.

Why is this? Couldn't you just take the file passed to you, add it to IPFS, receive the cid, and pin it? You wouldn't need to retroactively pin files that had been previously added would you?

There is also a concern with how encryption would be done on the private-store.

Ohh yeah this seems a bit tricky, didn't think about this. Would you be open for trying out with public stores (and threads?) first? If it seems like it's getting used, then this aspect could be revisited?

[oed]

Oh good point! I feel like it could go either way - images seem to be the most common file type in profiles, but I dont think it would be much more difficult to generalize it.

I kind of like the idea of starting with images actually. One thing that would be sweet as an addition to this would be if the file was saved in multiple sizes :F

Why is this? Couldn't you just take the file passed to you, add it to IPFS, receive the cid, and pin it? You wouldn't need to retroactively pin files that had been previously added would you?

Depends on what you mean by pinned here. It get's automatically pinned in the local ipfs node in the browser. The 3box-pinning-node would have no way of knowing about this file unless it checks the entries in the users DB. There is no way to tell a remote ipfs node to pin a file though the p2p protocol. Currently the pinning-node doesn't expose the https api (like infura) and that's nothing we intend on doing actually (except maybe a read only one in the future).

Ohh yeah this seems a bit tricky, didn't think about this. Would you be open for trying out with public stores (and threads?) first? If it seems like it's getting used, then this aspect could be revisited?

I guess it would be simple enough to encrypt the actual buffer though.

Overall I think this would be a super cool feature, but I kind of feel like we should hold off on it for a bit 🙂