Feature: Human-friendly share links

[CSDUMMI]

Is your feature request related to a problem? Please describe.
I have just recently tried to transfer a file from my laptop to my PC
via IPFS.
I have done this, without any knowledge of this project
and have thus first done this:

$ ipfs add myFile.js

On my Laptop and then typed every letter of the following CIDv0
in by hand on my PC.

$ ipfs cat <CID>

That is tedious work and I don't want to do it again.

Describe the solution you'd like
My idea for a solution is to create more easily
available links, that can also be easily typed by hand.
I imagine this not to be a hash of some kind,
that can not be remembered by the lazy mind,
but instead a human readable link, that can be
entered by the user themselves.

How to implement this.
Imagine a Peer I (for example my Laptop) tries to send a File A to Peer II
(my PC) and the only connection they have is that they have IPFS Daemons running:

1. Peer I adds A to IPFS: ipfs add A
2. Peer II subscribes to a pubsub topic called /sharing/A: ipfs pubsub sub /sharing/A
3. Peer I publishes the CID to A from 1. to /sharing/A: ipfs pubsub pub /sharing/A <cid>
4. Peer II receives the CID of A and gets that File from IPFS

I am not aware, if this will work with the current pubsub system and
I know, if you do not enter a sufficiently long name, this system will fail,
similar to how Jitsi Sessions are insecure, if their names are too short.

Perhaps this diagram is helpful at explaining this concept.

Describe alternatives you've considered
I saw, that there is already an issue for creating QR Codes from those
links, which does go in the same direction ipfs-shipyard/ipfs-share-files#78, but it is not
sufficient I believe, because in my use case, it would not help me at all,
to have a QR Code instead of a link.

Another alternative would be, of course, to use some kind of a
reversible hashing function, that reduces a CID to only a few characters,
but these functions have the disadvantage mentioned of being not
human readable still.

Additional context
IPFS PubSub is a subsystem introduced three years ago
and I do not know, how reliable it is as a subsystem by now.

1. Take a look at pubsub on IPFS

[welcome]

Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review.
In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We currently aim to give initial feedback within two business days. If this does not happen, feel free to leave a comment.
Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers:

• "Priority" labels will show how urgent this is for the team.
• "Status" labels will show if this is ready to be worked on, blocked, or in progress.
• "Need" labels will indicate if additional input or analysis is required.

Finally, remember to use https://discuss.ipfs.io if you just need general support.

[welcome]

Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review.
In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We currently aim to give initial feedback within two business days. If this does not happen, feel free to leave a comment.
Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers:

• "Priority" labels will show how urgent this is for the team.
• "Status" labels will show if this is ready to be worked on, blocked, or in progress.
• "Need" labels will indicate if additional input or analysis is required.

Finally, remember to use https://discuss.ipfs.io if you just need general support.

[jessicaschilling]

Hi @CSDUMMI -- thanks for your detailed explanation! I'm moving this to the ipfs-webui repo, since we're currently considering enhancements to Web UI/IPFS Desktop's Files screen and this is a concept that would most likely start there and make its way to the rest of the GUI-based tools (like share.ipfs.io) in time.

While we don't want to lose sight of the important distinction between content addressing and location addressing, you raise an important point about the ability to easily share URIs when means like a QR code aren't a good option.

[CSDUMMI]

I am currently working on a PoC on this GitLab Repository in JS IPFS.

I have not tested it yet, but in theory the following should transfer a file between Peers I and II:

1. Peer II listens for Files on FileSharePOC

$ # Peer II
$ node share.js receive FileSharePOC

2. Peer I shares a File on FileSharePOC

$ # Peer I
$ node share.js share example.txt FileSharePOC

3. Peer II receives the file

[CSDUMMI]

I have just tested the CLI App on my own machine, it worked.
But I cannot say anything about how well it works to transfer data between
peers run on different machines.

[jessicaschilling]

Suggest posting in the forums at discuss.ipfs.io to recruit a few testers?

[CSDUMMI]

I have done that here and provided some further documentation to the PoC repository.

[CSDUMMI]

One issue that I have, is that it seems,
that a message sent through IPFS PubSub does not seem
to arrive on the other Peer.