Browser dedicated to IPFS

1

What do you think of making a browser dedicated to IPFS?
I understand that IPFS is a mechanism to replace the existing Web, especially content distribution.

Currently we are accessing content with browsers like chrome
Can this be replaced by creating a dedicated browser for IPFS?

惻 Launching the browser starts the IPFS daemon behind the scenes and connects to the network.
惻Just type IPFS Hash into the URL bar. It converts behind the scenes to ā€œlocalhost:8080/ipfs/${IPFSHash}ā€.
惻ā€œIPFS searchā€ is installed in the search engine.
惻 It is so wonderful and ideal if it is compatible with mobile.

What do you think of this idea?

3 Likes
2

Interesting idea but I donā€™t think that forking an existing browser is the best solution. You donā€™t have to reinvent the wheel when lots of very talented people maintain browsers like Firefox or Chromium very well. All we want to have is just a native IPFS gateway on the browser, so I think a browser extension is the way to go. It would send all the IPFS/IPNS scheme URIs to the IPFS daemon, like in the URL bar (ipfs://{CID of website}/blog) but also in HTML (<img src="ipfs://{CID of photo}"> for example). This would be the best way to make an user-friendly IPFS in my opinion because it could be used along HTTP.

Optionally it would also be good to keep the same private key when you restart the browser. The IPFS web API should also provide things like access to the DHT, PubSub and end-to-end encrypted messages between 2 nodes for developing purposes (so things like IPFS-search could be done client-side). More generally, I think IPFS should start to consider implementing distributed computing if it longs for replacing the ā€œcentralized webā€ aka HTTP aka client-server architecture.

1 Like
3

@talb
Certainly forking the existing browser was a reinvention of the wheel, which was inefficient. I think you are right.
I think it is also user-friendly to provide access methods like the existing http.

However,
I think, the part of that download the IPFS binary and start the node from the terminal need to have a UI that is user-friendly and can use the existing http mechanism in the same way.

I found that IPFS Companion (https://github.com/ipfs-shipyard/ipfs-companion) is doing something pretty close.

I have been felt it was a very difficult issue by your response.
I will think deeper. Thank you so much.

1 Like
4

Thereā€™s an ongoing effort to integrate it as natively as possible n the Brave Browser. https://github.com/brave/brave-browser/issues/819
Info looks spread across several places unfortunately.

1 Like
5

@satoshi999 you can also try Siderus Orion ipfs client. Itā€™s great for adding files/folders to ipfs. You can also generate qr codes from your hash and share directly to facebook, telegram, twitter.

The client offers a lot of control over your ipfs nodes settings.

6

On one hand, I think walled-garden-like experiences are not so great; we wouldnā€™t want to repeat the mid-90ā€™s with things like Internet in a Box, AOL, Juno etc. At least not for the same reasons.

I think IPFS should eventually be a system service: you can count on it running as a system daemon 24/7. Thatā€™s the only way for the distributed web to become more reliable and actually supplant the old web: you have to help with your share of the hosting. (You should be able to set system-wide limits for bandwidth and storage, naturally.) It also means that every browser should eventually have direct IPFS support by interfacing with the daemon rather than by running its own daemon. Browsers that try to run their own daemons will tend to clash with pre-existing system daemons (just like we see with dedicated Ethereum clients - they tend to preclude running ethereum as a long-running process, but thatā€™s exactly what you should do if you are serious about using Ethereum).

On the other hand, I donā€™t actually like the current web all that much either. We should try to collectively work against the use of advertising and tracking to monetize everything.

So I have my own project: https://github.com/ec1oud/nettebook is a light browser for Markdown. I think for the free web (people sharing non-monetized content with each other as a community service, for wikipedia and projects like it, for social media, and so on), it makes sense to use markdown instead of HTML, because itā€™s easier to write, and because the limitations of Markdown make it easier to defend against the assault of those who want to make money from content at any cost. Nettebook is an HTTP client for the ipfs daemon that it assumes is already running on your machine; and it uses Qt for the UI. I recently added direct support for Markdown to Qt, in order to make such things possible. AFAIK itā€™s one of the first attempts to use Markdown directly as a page formatting language rather than as shorthand for generating HTML. However there are a lot of features missing compared to regular browsers: you can have rich text with tables and bullet lists and checklists, and you can have images - thatā€™s it. No client-side code running (because client-side code can be abused, and often is). Not having client-side code makes it hard to handle new content types or anything interactive. I can try to add specific features later, like mini-languages for vector graphics, mathematical renderings, and such; but Iā€™m very much repeating the early 90ā€™s in the sense that it has about as many features as Netscape 1.x, minus the CGI capability (and minus some basic things that I havenā€™t gotten around to yet, like bookmarks and history). But when I simply want to read text that somebody has written, in order to learn something (one of the main use cases for the web, after all, at least for me), itā€™s comforting to know that tracking and advertising are practically impossible on a platform like that. It canā€™t be done by code on the client side; and itā€™s hard to do by using tracking images, as long as the content comes from IPFS instead of by directly connecting to a web server. (But nettebook does currently have http support too. If most of the interesting content was available on IPFS, it wouldnā€™t need to.)

Of course there is hardly any pure-markdown content on IPFS yet. But Iā€™m proposing that there should be. I plan to publish a blog that way sometime soon, for starters. Of course there can be a JS rendering solution (strapdown probably) for regular browsers. Most people will end up reading the content that way, and I donā€™t care.

Nettebook is an editor. You can use it to edit local markdown files on your regular filesystem or on your local UnixFS/MFS; you can read and write a limited dialect of HTML; you can paste text from web pages into the editor and save it to markdown; and you can publish markdown directly to IPFS (sortof - you just get a hash for that one file, and it gets pinned, but thatā€™s it so far). I need to figure out how to make it manage collections of pages better, to organize a blog or any other sort of repository of writings.

7

Hello all.

Iā€™ve been working on this browser: https://github.com/eversum/galacteek , runs on linux and macos (you can get an image from the releases page).

8

Latest release (0.4.14) has EthDNS support: https://github.com/eversum/galacteek/releases/tag/v0.4.14

1 Like
9

@satoshi999 (This is one way to to encourage propagation of files in IPFS storage.)

I think one reason people are leery of hosting an unknown personā€™s files is because of liability. People would be far more willing to support IPFS storage if they were only storing a part of each file.

As an example, think of cat.jpg. It may or may not be a picture of a cat. It might be a dog. If you donā€™t like dogs, you might decide not to host any files at all. If instead of hosting cat.jpg, it is first made into a mosaic of 64 smaller segments of the original, then sure, somebody wouldnā€™t mind hosting that 1/64th of an image. The fur might be cat fur or dog fur, but you couldnā€™t actually know. Somebody else would be hosting another piece of cat.jpg, maybe the eye. If you had 64 people, the image could be distributed perfectly.

I believe there is some work underway already on such a system, but canā€™t remember for which project.

Another system which would help would require a unified method for ā€œlikingā€ content that could be used across applications. You would start by deciding how much love you had to give. (By love, we mean storage space.)

Whenever you saw content you appreciated, you would ā€œlikeā€ it, and this would translate to willingness to store a part of its mosaic on your disk. (The number of mosaic pieces stored could additionally be increased by an expression of intensity of like, ranging from like, love to adore, for example, representing 1, 4, or 16 pieces of mosaic.)

When somebody else requests cat.jpg as a download, it would be retrieved piece by piece from the 64 or so people who were hosting it, and then using local CPU processing reassembled.

At this point, the person could discover whether it really was a funny cat or a dog, if they hadnā€™t seen it already.

In addition to ā€œLovingā€ files, it might also be possible to hold a place in your heart for users. These could be content providers you wish to support, because they regularly make funny cat videos on their channel. You might also wish to offer some storage to users who are fulfilling a useful purpose in the IPFS ecosystem, like indexing or something like that.

Sadly, love doesnā€™t last forever, and your storage might not either. You could optionally love ā€œlong timeā€ or ā€œshort timeā€. Each user would of course decide what ā€œlong timeā€ actually means, a week, month or year.

ā€œShort Timesā€ might be very efficient at alleviating intense though shortly lived urges for content.

Periodically, one might ā€œrenew oneā€™s vowsā€, or ā€œreaffirm oneā€™s loveā€ by extending ones love for yet another month or year, depending on how much your love has been returned, perhaps.

10

I donā€™t think a browser plugin that works as an IPFS gateway would be enough, not even for a good start. At the moment the most urgent problem of IPFS in my eyes is the long latency, poor scalability. So even if you are connected to the public IPFS network, you would have to wait an hour to see your content, except your are already connected to the right node. Only if there were some support for dedicated or private IPFS networks, or sharding implemented inside IPFS, it would get useful inside the brower.