Get rid of the "browser" part

[RangerMauve]

What about this crazy idea: Instead of having Bunsen act as a browser that users install, it lets users use their default browser.

Instead of spawning an activity with a webview pointing to bunsen UI, what if Bunsen was an app that ran in the background and redirected dat:// urls to the gateway?

Users would install bunsen, and it would run the gateway in the background, as well as some sort of RPC over Websockets that would support the create / select functionality.

When users invoked selectArchive it would launch an activity that would prompt them to choose an archive, and then close to reveal the browser again, then the gateway would respond to the RPC.

Bunsen could have a UI for managing dats, but it wouldn't provide the actual browser component. That way people can use whatever browser they primarily want on their mobile devices and make use of the existing bookmarks and history that a feature complete browser would have.

The gateway can inject the dat-polyfill (or some version of it to work with Bunsen) and redirect to the lvh.me domain for loading the contents.

This is a hugely different approach and kinda gets rid of the concept that "Bunsen is like BeakerBrowser for mobile", but I think this will make it easier to onboard new users and spread the usage of the dat protocol and eventually make it obsolete once we get browsers to support dat by default.

Kind of a crazy idea, I know, and I'm not sure this is even a good path forward yet. I just wanted to throw this idea out there and see what y'all thought about it. I'm really excited about the technology and have been thinking about how we can get non-technical people to start using it.

[rjcorwin]

Thanks for bringing this up. It's definitely something to consider, especially since this is a volunteer project. Given the limited time we have and the fact we want this sooner than later, we need to minimize scope. The downsides to this approach I can think of at this time are...

1. If someone restarts their device and visits something in their Firefox/Chrome browser history that was a gateway URL without opening the gateway app first, they'll see an error without directions on what to do.
2. We won't have any UI on the site itself showing things like stats on peers.

I'm not so sure the second point is a problem because we'd have the UI in the gateway app. It's however, just a little disjointed I guess... And if we really wanted some kind of UI we could inject it similar to how we are thinking about injecting dat-archive-web.js.

An exciting way to look at this idea is it would be a Dat Client for mobile that happens to also have a gateway. In that case I'm happy to not even call this project "Bunsen", just "Dat for Mobile" if the Code for Science and Society folks approve.

[rjcorwin]

Something I had not thought of trying: enter a dat address in chrome or firefox on an Android device with Bunsen, it opens in Bunsen! That means you could still use the URL bar of Chrome and Firefox to enter Dat addresses, it would switch you over to the bunsen app, which would then send you back to Chrome or Firefox with the transformed URL for the gateway.

[rjcorwin]

My bad, I spoke too soon. Entering a Dat URL on Firefox works as described above, not on Chrome. Bummer!

[rjcorwin]

If we go this way it affects the assumption in "Support use of dat-polyfill #53" that when you are in a dat app being served from the gateway, that you will be inside of an iframe where the parent is providing a key service over pushMessage. However, we could reverse the relationship and it will work in both architectures. So instead of the dat app getting keys from its parent who put the dat app in an iframe, the dat app opens it's own iframe to the key service and communicates over pushMessage.

[rjcorwin]

Gateways could serve this key service app at something like http://keys.<TLDN>. It would be a generic app that would not have to store anything on the server side, just serve up the code for the key service so the browsers can store keys in their own local storage.

[RangerMauve]

Since the polyfill will be injected from the gateway, it won't have to have the code talking to the parent frame.

I think the current bunsen UI stuff will still be useful for a web-only UI for use with public gateways so Dat websites can still be usable without installing any new software.

That's a good idea with having they keys be stored in an iframe. We'd still have the problem of figuring out how to do a UI, but if implemented correctly the gateway wouldn't even need to do anything special for storing the keys, and they can be stored in the browser itself.

I think that instead of using a special domain, the key storage should be done in something that's published on dat. :D