ipfs-webui

ipfs-webui copied to clipboard

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

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.

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.

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.

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

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.

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

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

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.

I feel like we should be able to solve this with IPNS but only publishing on the local DHT. currently, the ipns publish modal only publishes IPNS records to the public gateway, and end up with long URLs that are just as human-unfriendly as a CID.

IPNS is a PKI namespace, where names are the hashes of public keys, and the private key enables publishing new (signed) values. In both publish and resolve, the default name used is the node's own PeerID, which is the hash of its public key.

I wonder if there's any local routing we can do similar to IPNS where nothing is published externally, and keys/signing/permissions for modifying the values are all handled by the user, and therefore, we can have simple references such as "/ipns2/myLocalOnlyKey"

@lidel thoughts?

We could set up a proxy server with webui for implementing this "ipns" type functionality at a specific path, so then users would just access http://myIpfsHost:port/localIPNS/myLocalOnlyKey