Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Handle ipfs://, ipns:// and dweb: system-wide

See original GitHub issue

We have kind of a bit stale issue (#35) about handling ipfs:// at a system wide level. With the help of Electron Builder (docs) we can easily configure one or more schemes to be handled by our program. Ideas ideas!!

Handle ipfs:// URLs and show a dialog asking whether to open it in the gateway or explore in IPLD Explorer. Wouldn’t a ‘Add to my repository’ option be interesting too? Or we could have a way of opening it inside Web UI and then Web UI would have those options (instead of showing a dialog).
Shall we handle ipns:// to and redirect to the browser?
Shall we also support .ipfs files that can contain an IPFS path? https://github.com/ipfs-shipyard/ipfs-companion/issues/641

macOS: works.
Windows: works.
Linux: ??

/cc @ipfs-shipyard/gui

Issue Analytics

State:
Created 5 years ago
Comments:8 (7 by maintainers)

Top GitHub Comments

1reaction

olizillacommented, Jan 29, 2019

The idea we talked about was to have ipfs:// scheme urls be handled so they open in ipfs-webui, in a new files browser page above the root of the MFS, that can show arbitrary CIDs and, in it’s default state introduces the files api and repo and MFS more generally.

That said, I’d say the MVP of this is to allow the user to open ipfs://* urls in their browser, assuming we can translate them to https://ipfs.io/ipfs/*

I agree with @lidel that we should focus this issue on what protocols we should handle, and keep the .ipfs symlink style files for a seperate discussion.

0reactions

hacdiascommented, May 21, 2019

Yeah, we did it that way to make sure they were always available. But we can detect if the daemon is on, and if so, use the local gateway.