Skip to main content

Mike Sugarbaker

Fuck you, logins!

5 min read

First, hands up if you remember Yacht Rock.

Second, when my old WordPress site got thoroughly hacked, I had the opportunity during the recovery process to reread every post I've ever made here at Gibberish. There are a few common threads, but the predominant one jumped out at me because posts I made about it as much as fourteen years ago are still current: why is it still so much damned work to do certain bits of web development that literally every site does? Why hasn't any layer of the tech infrastructure grown to handle them, or at least help?

Take as an example my number one nemesis, user authentication. Whether you're doing OAuth for logging in via Twitter and Facebook, and therefore doing intense multistep tangoes of cryptographic token trading, or just trying to let people recover their forgotten passwords without creating security holes, getting auth right is so hard that you can't even trust it to a library. Half the time, the libraries for your chosen platform are incomplete or have major security bugs; the rest of the time, their authors throw up their hands and say (...not really wrongly) that individuals should take responsibility for understanding such sensitive areas of their code.

But apps of any seriousness need to have logins... right?

Sometimes, when something is a hard problem to solve, that's because it's the wrong problem to solve. The web wasn't designed to support single-page applications, and it certainly wasn't particularly designed for what are essentially single-user applications. Canva is the example that springs to mind right now, but there are plenty of others: tools that are centered on individuals creating things, that happen to run in a web browser. Collaboration features sometimes come in, but those are only salient for a handful of apps; features that support discovering and sharing content from other users are often kind of a joke and always a bolt-on that could be entirely separate. Apart from those, these apps could have been written as native apps. Many argue that they should be.

The first single-user web app was the web itself - making a page of your own, before anyone dreamed that a service would ever do it for you. Everyone talked about how great and revolutionary "view source" was; it democratized creation, and so forth. But then things got a lot more complicated, and despite code-sharing services like CodePen and (on a lower level) StackOverflow, the web's default openness became increasingly meaningless. When so much of the meaning in the web was in its connections, why not do your publishing through connections? Why have anything of your own?

"View source" is not enough, hasn't been enough for a long time, was never really enough. The lack of a full, secure set of in-browser tools for trading and sharing code, and the resulting need for server-based services to pick up the slack, is possibly the fundamental flaw that led us to our current state of total cultural capture by a handful of huge corporations, mainly Facebook in my country. The CEO of Facebook is widely expected to run for president sometime soon.

Well, I'm working on a single-user web application, because the languages we build the web with are languages I speak, and because it's still so powerful to just turn up in the user's browser without their having to download and install anything. But I'm building it against APIs that are only available in Beaker, an experimental web browser that adds support for the peer-to-peer protocol known as Dat. Dat implies a whole new way of doing multi-user web apps, as distributed networks of compatible files on various Dat sites, brought together via JavaScript and augmented by more traditional web services. But that stuff's not even what I care about: when you're browsing a site via Dat, Beaker gives you a "fork this site" button.

If you find something you like, you can clone it, and just start making changes to your own copy. Like it's a HyperCard stack you got off a BBS in 1989.

That leaves out the importance of the web's connections - Beaker doesn't track or share these forkings, the way GitHub does - and the multi-user side of Beaker's capabilities is definitely going to be its main selling point. But I think this simple, SneakerNet-style brand of sharing could be more important than anyone guesses, perhaps even Beaker's own creators, for the simple reason that nobody has to log into anything. Sharing and collaboration can still be done, but those are separate applications, finally snapped clean. And no, Beaker isn't the first browser to do things like this - it's just modern, insightfully designed, and built on an IPFS-like base that does plenty of cool tricks. Since it's built with Webkit, you could make it your go-to web browser and scarcely notice you were doing it (It Happened To Me!). Unless you're on Windows - they're still working on that - I strongly recommend picking it up and exploring.