IPFS Based Browser

1

Hey all, do we have any plans for a IPFS Browser?

I’d like the NetScape time float over again… :rocket:

Only this time neat and nice with support for Proxy and all… :slight_smile:

1 Like
2

FYI, happy to help and contribute. Rust and Go guy here :raised_hand_with_fingers_splayed:

2 Likes
3

Creating a new browser is a mixed bag: if you do it for something other than PoC then it requires a lot of resources to maintain. For now we are working towards integration with already existing browsers:

There is also a dedicated repo for tracking “browser efforts”, which may be a good place to discuss planning and more technical matters. Check it, maybe there is something you want to help with :slight_smile:

5 Likes
4

I like browsers too…! :+1:
How about Servo? Making any progress (I have a rusty feeling :smile:)

5

Servo isn’t really a browser at this point (and is far from stable). We’d end up spending more time working on servo than integrating it with IPFS. That’s why we’re currently focusing on brave and Firefox.

My personal worry about implementing a new browser from scratch is all the additional features we’d have to work on (extension support, spell checking, ad blocking, security, security, security…) in addition to simply integrating IPFS.

2 Likes
6

Calling it a browser is a always a little bit strange, because a browser really has the context of a client - an IPFS “client” is really an active node participating in the network. A true dweb “browser” would be a hybrid, somewhere between (to give an example using things people understand) a bittorrent client and a web browser. That said, I prefer to call it a web browser, it’s clean and people understand it, and shows how things could be by providing a useful frame of comparison. Users can be informed that it’s a highly specialized browser for IPFS stuff with only a single sentence on the web site they download it from. Framing the browser context isn’t a problem.

I agree that a implementation of a “full” web browser would be troublesome. But it’s important to understand what is meant by “full”. With development frameworks like Electron, you get a programmable browser engine (the lion’s share of the browser work already done) which you can use to write a browser-like application that would work to load IPFS content (allowing us full control over the user experience), and I do think it makes a ton of sense to build something like that.

The important goal for me is to be able to use IPFS the same way today’s web users expect it to work, which is largely indicated by how the IPv6 rollout is being done: You could type in a domain, an IP address, or an IPFS hash, and it loads according to a procedure chart, first checking (if a domain) for a DNSLINK record, then falling back to HTTP with an AAAA record (if IPv6 is enabled), then trying HTTP IPv4, even if you don’t use a scheme/protocol (such as ipfs://). You get a proper security origin and all the learned assumptions you get from flowing downstream with the users of today’s web, without requiring them to learn a bunch of new things. This would enable people to make sites that are IPFS enabled but can fall back. End users (and even most power users) don’t care about the implementation details and they don’t want to manipulate command lines and JSON files - the interface is what matters. They want to load a site without thinking about it. “Any sufficiently advanced technology is indistinguishable from magic.”

It would then (and this is the best part) have a nice interface for managing web sites pinned and created by the user. “bookmarks” would really just be “pins” in this context. Now we have users not just playing around with IPFS, but actively participating in the network and helping to build it in a truly distributed fashion.

This could be it’s own app, or it could even be integrated into existing electron apps (ipfs-station). With js-ipfs it could (really, should) be a completely self contained solution with no external dependencies. You get to use nodejs, which helps with a lot of the “browser network stack” headaches too.

Doing this would not be difficult at this point. The bulk of the important work is just having a nice design for the interface. It would be a trivial level of difficulty for a skilled CSS designer/UX. I’ve worked on projects far, far more complex than this. The remainder is just gluing the design into React components and putting together a pipeline for js-ipfs.

Finally, this creates a nice demostration that can be shown to everyone, including people working on the major browsers, so they can clearly see the value prop and I do think would help to increase interest in major browser dweb integration. In the future after major browser integration, it won’t be difficult to just migrate people over to that experience.

I posted some thoughts on this a while back: https://github.com/ipfs/in-web-browsers/issues/53

7

@whyrusleeping mind sharing some points for go-ipfs here?

8

Hi @0zAND1z!

Here is a out of the oven update on the IPFS integration for the Brave Browser - https://github.com/brave/browser-laptop/issues/9556#issuecomment-352453877, make sure to check out the demo! https://www.youtube.com/watch?v=2cmbm6iABsI

1 Like
9

\o/ That’s awesome! Congrats!

Maybe allow a download button to pull the ipfs content? (file or an entire folder - directly to host’s Downloads folder in a Zip?)

10

Hello. I’ve been working on this project galacteek for a few months. It’s written in Python3/Qt5 and is fully asynchronous (it uses quamash, asyncio and aioipfs which i wrote).

I started writing the application to better understand how to write async GUI apps with python and qt5. I wanted to be able to browse resources on IPFS and create ipfs bookmarks that’s how it started There’s a file manager, media player and web browser and it’s integrated with the ipfs-search.com search engine. Currently i’m working on taking advantage of the pubsub/p2p streams functionnalities of ipfs.

3 Likes