
Show HN: Beaker – A browser for IPFS and Dat - pfraze
http://pfrazee.github.io/2016/08/10/beaker-browser-0.1.html
======
pfraze
Hey all, I'm the author of this project. Happy to answer questions or talk
about the software.

It took about 2 months to write. I used yo-yo[1] for the frontend UI, which I
enjoyed using a lot. The rest is standard es6 and electron.

Dat & IPFS are the first two protocols to get integrations. I also know
Maidsafe has been considering using Beaker as well. I might integrate SSB [2]
next, because of my history with that project.

Cheers.

1\. [https://www.npmjs.com/package/yo-yo](https://www.npmjs.com/package/yo-yo)

2\. [https://scuttlebot.io/more/protocols/secure-
scuttlebutt.html](https://scuttlebot.io/more/protocols/secure-
scuttlebutt.html)

~~~
kodablah
> Beaker is built on Electron, which is a temporary solution. Electron breaks
> Chromium's process-level sandbox, which needs to be restored. Electron also
> has API limitations, which (for instance) keeps Beaker from injecting new
> Web APIs into iframes and workers. So, in the near future, we'll need to
> fork Electron.

Can you explain how the process-level sandbox is broken using webviews?

Also, I hope y'all don't have to fork Electron but instead can upstream your
changes. I have successfully implemented web APIs that use private IPC to
communicate w/ the backend side (and then killed node integration). Granted I
have not attempted this with iframes and web workers...I wonder if it's just
an oversight on their part and would welcome a PR. I know the webview and
custom protocol support leaves a lot to be desired. But I fear all of these
Electron forks (e.g. Brave) for browser use will end up fragmenting features
that could help all browser implementers.

On a side note, this is really awesome. I have not dug into it too deeply, but
as I have mentioned before here and on the maidsafe forums, this is a big step
towards removing user tracking while leaving JS functionality intact. Simply
removing the "server" or mutable calls of the implemented protocol (or at
least making them opt-in) prevents the fingerprinting from being "phoned
home". I hope this project succeeds.

~~~
pfraze
> Can you explain how the process-level sandbox is broken using webviews?

Sure thing. It's the node integration that's an issue. To let the render
processes import node's APIs, the process-level sandbox had to be removed.
Whether node-integration is enabled or not, that process-level sandbox is
gone. The _javascript sandbox_ is still present, but the _os-enforced sandbox_
is gone.

This situation isn't totally unsafe, but it's not as safe as it can be. The
process-level sandbox acts as a strong second-line of defense against API
compromises. For a project that doesn't need node integration in the browser
(such as Beaker) then it'd be best to re-add it.

> I hope y'all don't have to fork Electron but instead can upstream your
> changes.

That would be nice! The team that works on Electron is superb, but they've
explicitly stated, in conversations with the Brave team, that they're not
interested in supporting Browser projects such as Brave or Beaker.[1] Their
position is reasonable - though obviously I'd prefer they changed it. I'll
stay in touch with them, and do my best to contribute upstream when it makes
sense. If I don't have to fork, in the end, I certainly won't.

1\.
[https://github.com/electron/electron/issues/5210](https://github.com/electron/electron/issues/5210)

------
mxuribe
@pfraze: This browser is a great idea! I'm getting more and more into
decentralized web stuff, and this browser is exactly the kind of thing for
decentra-newbies like me to keep diving in! Kudos!

[decentra-newbie or decentra-newb: a term i just now coined to refer to
newcomers or novices utilizing decentralized digital technologies. ;-) ]

Also - off-topic - but I just checked out the patchwork project, and wow, very
cool! I'm in the midst of running an internal/family-only experiment running
my own matrix.org server...but when i have a free chance, will definitely
check out patchwork.

Keep up the great work!

~~~
brokenmachine
Patchwork seems interesting.

How I'm picturing it is a kind of anonymous decentralized Facebook. Is that
about right?

~~~
whimful
that's pretty much it. You store a copy of your world of content out to 2
degrees of connection. Messages are gossiped along lines of trust
(friendship)... technically it doesn't even need the internet, just computers
periodically bumping into each other and gossiping

------
fiatjaf
How is that different from using a browser extension to browse
[https://ipfs.io/ipfs/](https://ipfs.io/ipfs/) links that get translated to
localhost?

------
qwertyuiop924
This introduced me to IPFS. I was already aware of Matrix, which had a lot of
very cool work done on it, which very much sold it to many of us as "what XMPP
should have been." Although XMPP is still a very viable protocol...

OTOH, I've heard a lot of dodgy things about Etherium, particularly from the
currency side, and just the security in general.

IPFS is exciting, looking very much like Freenet from a publishing
perspective, but without making anybody who want to see that data download a
very cumbersome program (and the security, of course). The history system is
also interesting. However, the single client and server implementation
concerns me. Especially because it's written in Go. I don't make judgements
about code quality by language (plenty of good programmers hack in Node and
other JS environments), but if we're going to use this thing as the
distributed platform of the future, it had better be cross-platform. And Go
has a... Less than exellent track record for being easily ported (I won't go
so far as to say that Golang Is Trash, but that post alone speaks volumes
about the porting experience, and there have been plenty of others). Plenty of
organizations run on BSD, Solaris, Illumos, or another Unix. If the future is
coming, I'd rather they be part of it, and even if Go runs for them, I'd
rather not make it any harder on then than necessary.

~~~
viraptor
You realise you're talking about system with 3 live implementations (one
complete/reference) [https://github.com/ipfs/ipfs#protocol-
implementations](https://github.com/ipfs/ipfs#protocol-implementations) with
the reference implementation being tested on every commit on linux+osx,
working on freebsd ([https://www.freshports.org/sysutils/ipfs-
go/](https://www.freshports.org/sysutils/ipfs-go/)), and windows
([https://github.com/ipfs/go-
ipfs/blob/master/docs/windows.md](https://github.com/ipfs/go-
ipfs/blob/master/docs/windows.md)), right? Finding other systems left as an
exercise to the OP.

~~~
qwertyuiop924
Sorry. I clearly didn't do my research well enough.

But so many of these systems have only one implementation, and no spec.
Matrix, Dat, and IPFS are all ahead of the game on that, even though Matrix
has only one server implementation, AFAICT, and all the Dat tooling I've found
is in node. It's better than Scuttlebot, in any case.

------
zbyte64
How are you shipping IPFS with your electron app? I was under the impression
only the GO implementation of IPFS is complete. Are you simply running IPFS Go
as another process? (And where is it being included? I couldn't find it in the
code base)

~~~
pfraze
Have a look in [https://github.com/pfrazee/beaker-plugin-
ipfs](https://github.com/pfrazee/beaker-plugin-ipfs). (All protocols and web
apis in beaker are plugins.) The Go binary is distributed via npm, and spawned
as a daemon.

------
starquake
I know looks are not the point of this browser but the tabs look great! Much
better than the Chrome tabs!

~~~
plainOldText
I was actually having the same thought while watching the video. I'm glad to
see other people pay attention to these small details. (:

------
dharma1
really looking forward to the next generation of distributed internet. I think
those IPFS addresses need to be a bit more human readable though :)

~~~
bradyd
They have a related name service for friendly names, IPNS, however it's
difficult to find more information about this service.

~~~
pfraze
There isnt a doc available yet, but there are two key properties. The first
is, you can create mutable IPFS archives by generating a keypair; the pubkey
becomes the identifier, and new versions are signed by the private key.

The second property is, you can use DNS TXT records to provide shortnames that
map to the pubkey (or, I believe, to a static hash-id also). Run 'dig txt
ipfs.io' to see an example.

EDIT: this is also helpful
[https://github.com/ipfs/examples/tree/master/examples/ipns](https://github.com/ipfs/examples/tree/master/examples/ipns)

~~~
p4bl0
And it works really great! I've been serving my personal web page for months
now at /ipns/pablo.rauzy.name :).

The only catch is that you need to republish regularly (I do it using cron two
times a day) otherwise the IPNS do not work after some time, but I'm not sure
it still is the case.

