-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
share.ipfs.io - pcp interoperability #127
Comments
@dennis-tra I'm happy to brainstorm some sort of vendor-agnostic interop spec that could be used across sharing tools, but embedding pcp in this app as a drop-in does not seem to be feasible.
|
Hi @lidel , sorry for the late reply and thanks for your thoughtful answer. Your points sound totally reasonable. I'd need a more thorough look through the codebase to be able to discuss this further as the interop was just a thought that came to my mind. I'll just ping you on this issue when I got the time 👍 |
Hi @lidel, I finally had a look through the code. I would like $ pcp fetch https://share.ipfs.io/#/bafybeie3i6irbahdr4ryzsxx6xoncza2cblq7duya67bimfraig3mq5kgi This would fetch the data directly from the browser of the peer. Similarly, $ pcp share somefile.txt
Link: https://share.ipfs.io/#/bafybeie3i6irbahdr4ryzsxx6xoncza2cblq7duya67bimfraig3mq5kgi Here the user would need to leave the tool running until the content was transferred - similar to the current UX. I saw that I still have trouble to completely grasp the peer and content discovery flow though. Please correct me if I'm wrong:
Now I'm wondering how content is discovered if the app is opened with the CID url fragment. If my understanding above is correct I could imagine that:
Other questions:
Edit: Started a conversation here: https://discuss.libp2p.io/t/share-ipfs-io-peer-and-content-discovery/894 |
(missed the notification for this 😿 – apologies for delay in response) Answered some of remaining questions about libp2p setup in https://discuss.libp2p.io/t/share-ipfs-io-peer-and-content-discovery/894, so just to comment on proposed UX, sounds good. Content routing to/from browser node remains the main challenge here. Some thoughts if you want to maximize utility in the browser by leveraging existing preload infrastructure:
Those are optional, but if enabled by default would improve time-to-first-byte. |
This issue was opened a long time ago.. I like the idea of updating PCP to output a link to share.ipfs.io, and I like the idea of share.ipfs.io outputting a CLI command for downloading the file(s).. this is still worth doing, but the landscape has changed since we started using Helia and js-libp2p in #138. We may have better viability for interop now. |
Hey there,
maintainer of
pcp
here. I had browser <-> CLI interoperability on the roadmap from the get-go. In the most recent IPFS newsletter I learned about this project and thought I may just hook into this existing web app. Currently, the protocols to exchange the identifier and file transfer differs significantly between both tools.My question, would it be of interest to you if I integrated the word-sequence protocol into this web app? Or is it an unpromising thought that this would land here - which would be fine of course. I just want to set realistic expectations right from the start.
What I'll probably do anyways is adding the
share.ipfs.io
protocol topcp
which doesn't interfere with you - I'm interested in the other way around.Best,
Dennis
The text was updated successfully, but these errors were encountered: