Paul Frazee

I work on a peer-to-peer browser called Beaker. I live in Austin TX and work at a company called Blue Link Labs. We run a public-peer service called Hashbase.

RSS Feed

<-- home

Beaker Browser 0.2

Beaker 0.2 is released today for MacOS. This release adds the auto-updater, IPNS support, a new logo, and a set of bugfixes.

Please file any issues you have at the GitHub repo. You can tweet @pfrazee for additional support, or join #beakerbrowser on Freenode to chat.

[ Download for MacOS | build from source ]

In the next release, Beaker will include new features that make publishing on the P2P networks both convenient and fun. I’ve been reaching out to the community, and received great feedback about what this should include. I look forward to putting it in your hands.

New to Beaker? Read the introduction here.



About the plugins

Beaker supports plugins, which add Web APIs and URL schemes. Part of our mission is to give decentralization teams a place to experiment, in ways that existing browsers couldn’t support, and this is how.

For a time, Beaker’s dev-branch had an installer for plugins in the settings page. This feature was cut just prior to release. Pulling from an issue, here’s the reason why:

I was discovering a lot of difficult edge-cases in the in-browser plugin installer, which made me worry that, without proper infrastructure to support this complex of a feature, the product would be be buggy. Building Electron for multiple platforms is already pretty difficult; making a more complex packaging system, like this, would be much worse.

The feedback I’ve received from other protocol designers is somewhat split. While I think some protocol devs would strongly appreciate having the in-browser plugin installer, there are others who are more likely to need a custom packaging or fork of beaker. Therefore, since protocol engineers are, ultimately, a minority of Beaker’s intended users, and, among them, the need for an installer is divided, I’ve decided not to make this a priority.

Docs have been updated to reflect the new solution: plugins are installed locally, and Beaker must be rebuilt from source to enable them.

I hope this isn’t disappointing. I want to provide a high standard of quality for all users - not just the decentralization teams - and I felt this added too much risk.

Teams will now experiment with their tech using custom builds, as documented here. I’m working with the MaidSafe team to make a “SAFE” variant of Beaker with this new approach, and we’ll keep improving the tools as we understand the requirements more.


The updates domain

PS, if you ever look behind the scenes, you’ll notice that auto-updates are served from beakerbrowser.net, instead of .com. Why? Because my friend John thought it would be funny to snag the .com and put this up:

We had a laugh1, but when he transferred the domain to me, the registrar flagged it for potential fraud and we got bogged down in bureaucracy. I went with .net so I could keep development moving.



1 The joke, explained: Brand confusion, I prefer yo-yo to React, and he’s been trying to get me into Destiny for months now.


-pfrazee



Tweets: twitter.com/pfrazee

Code: github.com/pfrazee

Creating a peer-to-peer Web: beakerbrowser.com