Reviving BrowserID: Building a Decentralized Identity System for the Bespoke App Era

In 2026, as the boundaries between personal and digital continue to blur, a developer known as Wakamoleguy is breathing new life into BrowserID, an identity protocol that died nearly a decade ago. His project, WKID (Wakamoleguy's Identity server), aims to solve a growing problem in the age of AI-assisted development: how to manage user authentication for small, bespoke applications without relying on corporate identity providers.

The current landscape of application development has been transformed by Large Language Models, which have dramatically lowered the barrier to entry. Developers can now turn ideas into working applications with unprecedented speed, leading to an explosion of small, bespoke projects designed for solo use or sharing among close friends and family. These applications are, by definition, free-as-in-freedom, as the user is often the developer who can modify them to their specific needs.

However, even for personal projects, user management presents a significant challenge. "I don't want to reinvent user management again and again for each service," Wakamoleguy explains, "and yet I also don't want my American Girl Doll shoe collector companion app to be dependent on the values of Google, Auth0, or some other corporation that could decide to suspend my account."

This is where BrowserID comes in. Originally developed by Mozilla and later abandoned in 2016, BrowserID offered a federated approach to identity based on email domains. For developers who control their own domains, this means complete control over authentication flows without third-party dependencies. The protocol is privacy-preserving by design—the identity provider doesn't see which sites its users are logging into—and uses email addresses as identifiers, eliminating the need to separately collect and map credentials.

The BrowserID flow resembles OAuth but with important differences. When a user clicks a "Log In" button on a site, they're prompted to enter their email address. Based on that domain, they're routed to their identity provider, where they authenticate. The IdP then provides a cryptographically signed assertion of the user's identity back to the original site, which verifies the signature and creates a session.

BrowserID ultimately failed due to a classic chicken-and-egg problem. Identity providers had no incentive to join the federation unless enough relying parties were using it, while relying parties didn't want to adopt it unless their users' identity providers supported it. Mozilla attempted to solve this by hosting persona.org as a fallback IdP that could verify any email address, but traction remained insufficient.

WKID sidesteps this issue by changing the scope entirely. Rather than attempting to win the global identity provider market, Wakamoleguy is building WKID specifically for his own use and that of his family and friends. "If I only have a handful of my own hobby services using it, and only for one user, that's still a win," he notes. Any broader adoption would be a bonus rather than the primary goal.

This focused approach also allows WKID to avoid the complexities of email deliverability, abuse prevention, and reputation management that plagued BrowserID. "Because actually sending email is a whole can of worms," Wakamoleguy explains, "I'm not planning on hosting fallback IdP functionality at all. This means that users won't be able to use my apps unless their email domain provider supports WKID. And the big providers will never be supported."

While this limitation would be a dealbreaker for a commercial identity service, it's perfectly acceptable for the bespoke app ecosystem WKID targets. For personal projects where the developer controls both the application and the email domain, this approach provides a clean, dependency-free authentication solution.

WKID is currently in development, with end-to-end flows functional and tested. The remaining work involves styling polish, documentation cleanup, and simplifying self-hosting instructions. Wakamoleguy brings over a decade of experience building web SaaS applications and a long-standing affinity for BrowserID, having worked on unified communications apps that relied on email, XMPP, and SIP addresses—all of which follow the user@domain format that BrowserID leverages.

As the bespoke app ecosystem continues to grow, projects like WKID represent an important counterpoint to the centralization of identity services. By reviving and adapting BrowserID for today's development landscape, Wakamoleguy is offering developers a way to maintain control over their own authentication infrastructure without sacrificing security or convenience.

For those interested in following WKID's development or potentially implementing it for their own projects, Wakamoleguy welcomes advice from those with authentication service experience and encourages others to reach out if they'd like to try WKID with their own projects.