search

ipfs / ipfs-gui

Creating standards and patterns for IPFS that are simple, accessible, reusable, and beautiful
105 stars 17 forks source link

Design: Share files via IPFS #34

Closed olizilla closed 4 years ago

olizilla commented 6 years ago

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: https://github.com/ipfs-shipyard/ipfs-companion/issues/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 commented 6 years ago

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 commented 6 years ago

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 https://github.com/ipfs-shipyard/pm-ipfs-gui/issues/37) so existing users are fine, and we don't exclude users we haven't met yet.

olizilla commented 6 years ago

https://github.com/ipfs-shipyard/ipfs-companion/issues/423 - Display IPFS addresses instead of opening uploaded file

akrych commented 6 years ago

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 commented 6 years ago

Yes! :+1: My thoughts on what the page should have:

olizilla commented 6 years ago

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

Sender

screen shot 2018-03-22 at 14 51 29

Send via email

screen shot 2018-03-22 at 14 51 41

Send via link

screen shot 2018-03-22 at 15 19 20

Recipient

screen shot 2018-03-22 at 14 52 22 screen shot 2018-03-22 at 14 52 30
olizilla commented 6 years ago

Drag n drop a file to share it

Slack

screen shot 2018-03-22 at 16 18 13

web.whatsapp.com

screen shot 2018-03-22 at 16 19 14

alanshaw commented 6 years ago

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.

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

JonKrone commented 6 years ago

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:

image

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, https://github.com/ipfs-shipyard/peer-star/issues/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 commented 6 years ago

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 https://github.com/ipfs-shipyard/pm-ipfs-gui/issues/35#issuecomment-373929197.

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: https://github.com/ipfs-shipyard/pm-ipfs-gui/issues/34#issuecomment-373926710). 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 https://github.com/ipfs-shipyard/pm-ipfs-gui/issues/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 https://github.com/ipfs-shipyard/pm-ipfs-gui/issues/53 to track that specific use case. I had it planned for IPFS Companion, thank you for reminding me about it!

olizilla commented 6 years ago

More prior art

hacdias commented 6 years ago

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?

image

olizilla commented 6 years ago

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

olizilla commented 6 years ago

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

lidel commented 6 years ago

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

We started working on IPFS Share App:

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

lidel commented 5 years ago

More prior art:

lidel commented 5 years ago

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 commented 5 years ago

instant.io

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

2019-07-16--11-41-07

jessicaschilling commented 4 years ago

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.