Design: Share files via IPFS

[olizilla]

How do we make sharing files via IPFS feel great? It's the first thing I tried to do with IPFS, and I think it's something we should invest some time into making really good.

This is closely related to "Add files" #35 and "File Browsing" #9, as you might want to add and share a new file, or browse for a file you added to IPFS previously and (re)share that.

Related issue on companion: ipfs/ipfs-companion#342

The current state of things is described here: https://github.com/ipfs-shipyard/pm-ipfs-gui/blob/master/research/README.md#sharing-files

[olizilla]

Sharing right now consists of choices like "Should I share the public gateway http link, or should I share the /ipfs/Qmhash path". The apps all do variations on that. I think we can do better.

We'll always offer the user a url they can copy/paste (much like the copy to clipboard share action on android), but we could offer a more polished sharing experience, where we create an beautiful html page that includes a clear download button to for the file the user wants to share, along with the filename, it's size and it's CID. The CID for the download page would be given to the user, instead of the selected file CID.

The page could provide a concise explanation of IPFS, and a link to more info, along with an call to action to install IPFS so that they too can share files with peers without needing intermediaries. GET ON BOARD THE PEER-TRAIN! 🚋 🚋 🚋

When the recipient clicks the link (probably a http, central gateway flavoured link for now) they see the lovely download page customised just for them. It gives them a moment to consider if they want to download it at all, and invites them to install IPFS to download it directly from their peers if they want to join the fun, or just grab the file and get on with their lives, but now with a new idea in their head that there might just be a better way.

Offering an explicit "Share this file" action would connect up nicely with the idea of being able to indicate to group of friendly peers that a specific CID is gonna get linked to, and they should take note and pin that hash to increase it's availability, discussed in #36 "pinning buddy system".

[olizilla]

At the simpler end of things, we need to talk about the 4 flavours of IPFS address and how we express that to users.

I'd suggest that right now, for the purpose of interop and progressive enhancement, we should always offer the user the http, gateway url flavour when offering shareable links to files. We can show the NURI style CID as info about the file that they can choose to copy and paste, but anything that is labelled as "Share this file" should be giving the user a http link.

Companion can grab that and redirect it to a local IPFS repo, (See #37) so existing users are fine, and we don't exclude users we haven't met yet.

[olizilla]

ipfs/ipfs-companion#423 - Display IPFS addresses instead of opening uploaded file

[akrych]

When the recipient clicks the link (probably a http, central gateway flavoured link for now) they see the lovely download page customised just for them. It gives them a moment to consider if they want to download it at all, and invites them to install IPFS to download it directly from their peers if they want to join the fun, or just grab the file and get on with their lives, but now with a new idea in their head that there might just be a better way.

Love the idea :) 👍 What should we have on this page? File preview, CID, button to download, encouraged to install IPFS, download button, short explanation of IPFS?

Offering an explicit "Share this file" action would connect up nicely with the idea of being able to indicate to group of friendly peers that a specific CID is gonna get linked to, and they should take note and pin that hash to increase it's availability, discussed in #36 "pinning buddy system".

But for now it should be only button to "share" and then popup with the possibility of
copy the link to this "special download page" or send it directly to friend on e-mail?

[lidel]

Yes! 👍 My thoughts on what the page should have:

• visible IPFS logo and branding
• name and size of shared file/directory
  • eg: persian-room-guardian.jpg ~117KiB
  • the most important element, should visually pop to instantly see what was shared
  • it could be accompanied by a file (or directory) icon
    (we plan to support sharing entire directories)
  • can be clickable, but should point at "shareable" URL (below)
• "shareable" link to the file at our public gateway that user can send to a friend on IM or via email
  • eg. https://ipfs.io/ipfs/QmRAJM5ByzuKKpzKKisGDwBPHzYqMvVrYC2PcVhkMnP3gd/persian-room-guardian.jpg
  • accompanied by "copy address" button/icon
• a short disclaimer informing uploader/receiver that public gateway does not guarantee availability of content after X hours
  • main reason: we need to be explicitly honest about gateway not keeping files forever, so there is no negative UX when not pinned content disappears from public gateway next week
  • secondary reason here is nudging users to install IPFS and pin content they care about to stay available for longer
• indicator of health (peer count obtained via ipfs dht findprovs)
• a longer section with additional info
  [this may be optional, displayed only if user has no IPFS (eg. no window.ipfs is found)]
  • short explanation of IPFS
  • a call to action to install IPFS so that user can
    • share with peers without needing any intermediaries
    • pin files that should be available longer that the time offered by public gateway
  • I'd love to include @Mr0grog here, as he may have a very good intuition on what exact text should be used to convey all of this info in a short and digestible form.

[olizilla]

Using https://wetransfer.com/ to share some files with <20 people via email or shareable link, looks like this (such much advert)

Sender

Send via email

Send via link

Recipient

[olizilla]

Drag n drop a file to share it

Slack

web.whatsapp.com

[alanshaw]

I'm possibly getting ahead of myself here but, we should "standardise" the format of the shared file(s) so that it's easy to extract/link to the data from the download page or without having to view the download page at all.

QmHash/index.html <--- the download page with all the info
QmHash/.share-v0 <--- indicate this is a shared file/folder with a download page
QmHash/data <--- always a **folder** with the shared file enclosed

index.html - the download page which can link directly to the hash of the file (if a single file) or to the hash of /data if multiple

.share-v0 - is just a placeholder file so that if we ever are given a hash and programmatically want to get hold of the data, we can inspect the directory contents and see that it is a share page and then download/display /data.

It could also contain machine readable metadata about the share...? e.g.

• Title
• Description
• Content type (display a video player if video etc.)
• "Main" - file path (and hash) of file considered to be the "entry point"
• One day, index.html can just use window.ipfs to read .share-v0 to populate the download page content
• Share date
• File count?
• I'm just making this up...

/data - always a folder so that in the case of single files we can retain a file name

[JonKrone]

Hey guys, wanted to share some thoughts and questions as someone new to these projects:

---

Is file sharing a separate pane/feature within the WebUI or is it an action available in the File Browser? Most of the examples so far have been of modal-like interfaces which you then add items to but I was thinking of something more like below:

Clicking Share could then open a modal where you can add options. Perhaps we don't need options, though, and can just present the user with a clickable and copyable ipfs.io/ipfs/hash link at the top and a Share with email button right beneath it.

---

If it's an action in the File Browser, uploading multiple items has a different UX flow. If we want to enable that, then we'd need to use something like.. checkboxes?

Say, you have a vacation photos folder but only want to share these X items with your grandma. Do you share them each individually or can we batch select some to send? Do we then email or display a list of all the individual links shared? Should we create a new folder with only the shared items and link that?

---

Do we need clear messaging that the items you're sharing are immutable and changes you make locally won't reflect? Something like "You're sharing a snapshot".

Alternatively, do we want to use IPNS to share? Or perhaps have an option to 'live share' that uses IPNS?

I wrote about a dapp, peer-base/peer-star#1, earlier this week that has a solution to this with another abstraction on top of collections of files. It would basically use pubsub to emulate IPNS but is intended as a web-first client that doesn't require a node and wants to have more features like access control and simultaneous editing. Perhaps we could offload this work to a service like that.

---

@alanshaw what do you mean by "Main" - file path (and hash) of file considered to be the "entry point"? I imagine you guys have had this conversation before but do we need to be careful about revealing paths? Something like Qmhash/a/shared/file/ reveals a root folder that someone could then explore, right?

---

There might be some potential for access control features that might be usable in the WebUI in the future (unclear how right now). Do we want to think about that? For example, a password field in the Share dialog?

[lidel]

Is file sharing a separate pane/feature within the WebUI or is it an action available in the File Browser?

I am confident the "Share" button will be available as a context action within File Browser, like in your example. It is an obvious way to share existing files. There is a related discussion about "Adding things to IPFS" and tl;dr is around #35 (comment).

If user wants to share only a part of a directory, she can use File Browser to create a new directory, copy desired things there, and share this new root via context-action on it. It is elaborate, but does not require writing any new UI for this use case.

I'd say our focus here is on sharing static snapshot and for Share action to generate "landing pages" that can be shared instead of raw CID or dir listing (details: #34 (comment)). It is crucial for it to have IPFS branding. When people start using it and sharing with friends, we will get positive PR for free :)

Do we need clear messaging that the items you're sharing are immutable and changes you make locally won't reflect? Something like "You're sharing a snapshot".

Agreed. Words that convey it is a static snapshot need to be present somewhere.

Alternatively, do we want to use IPNS to share?

Exposing mutable data (a dynamic folder under /ipns/<PeerID> etc) did not exist in old WebUI and it should be a separate feature. Created #52 for tracking that specific case.

I imagine you guys have had this conversation before but do we need to be careful about revealing paths?

No, it is just cosmetics – we want URLs to be as short as possible while remaining valuable (provide human-readable names etc).

There might be some potential for access control features that might be usable in the WebUI in the future (unclear how right now). Do we want to think about that? For example, a password field in the Share dialog?

Simple symmetric encryption is a low hanging fruit, I created #53 to track that specific use case. I had it planned for IPFS Companion, thank you for reminding me about it!

[olizilla]

More prior art

• live sharing example in js-ipfs docs: revamp exchange files example js-ipfs#1343
• ipfs-senc https://github.com/jbenet/ipfs-senc
  

[hacdias]

I've got a simple question I need to make sure. On WebUI we have a Share button. After clicking on it, we should get some link for a page like the ones on this issue, right?

[olizilla]

@hacdias yes. first pass would be this https://projects.invisionapp.com/d/main#/console/13924274/296567139/preview

[olizilla]

i don't think we want to hide the navbar though... if you can get a first pass working, we can review it.

[lidel]

Some additional UI examples on extension front (WeTransfer was already mentioned in this issue):

• https://blog.mozilla.org/addons/2018/08/17/share-files-easily-with-extensions/

---

We started working on IPFS Share App:

https://github.com/ipfs-shipyard/ipfs-share-files

[lidel]

More prior art:

• https://dweb.page (just landed: https://twitter.com/davidhawig/status/1065996471974199303)
  It requires a writable IPFS gateway and provides simple toggle for encrypting before upload:

  

[lidel]

send.firefox.com

Send uses end-to-end encryption to keep your data secure from the moment you share to the moment your file is opened. You can trust that your information is safe with Send. It also offers security controls that you can set. You can choose when your file link expires, the number of downloads, and whether to add an optional password for an extra layer of security.

[lidel]

instant.io

Sharing with WebTorrent https://github.com/webtorrent/instant.io

[jessicaschilling]

Closing this as stale and prior art has evolved quite a bit in the interim -- also, we're hopefully doing some cleanup in https://github.com/ipfs-shipyard/ipfs-share-files in the near future. Please feel free to re-open if necessary.