Atmospheric Login Diary 1: On the Button - the divy zone

Atmospheric login is one of those topics that maintains a constant hum of discussion in our ecosystem, and for good reason: it's how everyday folks make their way into our burgeoning, internected web of apps. I'd like to explore this in some depth, so consider this the first of several diaries.

Logging on

As someone whose job description says, verbatim, “grow the Atmosphere”, open questions about login have become something of a fixture in my mind. Because there are some real stakes here for the network. After all, end users are going to base their understanding about what the Atmosphere is through this ordinary experience of getting logged-in. The app you’re building today is going to mediate somebody’s very first moment in the Atmosphere. Right out of the gate we are contending with global identities, hosting, apps, and imprinting basic ecosystem-wide UX expectations. And time is of the essence: 2026 is the Atmosyear, which to me means that the Atmosphere begins gaining purchase in the mainstream. We want these users to find their way in and decide to stick around.

To make this happen we need to be in touch with everyday users who are just trying to have some fun online again. Fun is usually low friction; fun is feeling in the loop rather than confused. Fun so often begins with the familiar before transitioning to play and experimentation.

I believe that is the core question for Atmospheric login: how can we just make login feel easy and familiar for folks? It’s also not just about end users, the same applies to builders too. Let’s look at what has come before, what’s ahead, and how to keep moving today.

Web past

Atproto takes a “no step backwards” disposition towards Web 2.0. That is why we support and even promote big, global indexes, for example: this is often the most effective way to build social experiences that users have come to expect. We can apply the same line of thought to Atmospheric login. Our framing then becomes: can we match the login affordances from centralized Web 2.0 experiences without bringing the perverse incentives of that time period along for the ride? In an effort to map this out, let’s take stock of the prototypical Web 2.0 login flow.

Here’s what usually happens, painstakingly documented in Google’s sign in button user journeys.

An app decides to use Google (or Facebook, Twitter, etc.) to facilitate login. They place a branded login button on their site.
The user recognizes Google, and probably knows that they already have an account with them. They click the button, and an account picker appears.
The user recognizes their account in the account picker and clicks it. If it’s the first time the user has used this website they will be presented with a consent screen, ensuring it’s alright to share their information and Google resources with the app they’re logging into.
The user clicks “Continue” and is directed back to the app where they are now logged-in.

Credit where credit is due. Here’s what Web 2.0 has going for it:

It’s recognizable. Doesn’t matter if the app you’re on is unfamiliar: you recognize Google.
It’s low-friction. Three button clicks to login to a new app for the first time. Just scanning and clicking, no typing.
It’s continuous. As you navigate across apps your account picker moves with you, offering you the same accounts to login with.

Web yet to come

As much as there is to learn from Web 2.0 login, the Web platform has been working on standards to improve from there. And it turns out that Atmospheric login is likely to have a place in this future Web. The main effort is a standard that will be supported by browsers called Federated Credential Management, or FedCM. Let’s look at how FedCM iterates on Web 2.0’s login story. Can it do better?

Yes it can. There are a couple key UX improvements that FedCM will bring to the Web.

Those nice Web 2.0 account pickers were per-platform. If an app allows you to login with either Google or Facebook, that means there are two buttons and each one sends you to a different account picker listing different accounts. In FedCM there’s just one account picker, and it can show you accounts you use on both Google and Facebook.
You might have heard of the “NASCAR problem,” referring to the common issue where a site will show you a bunch of login buttons including for providers you may not use, cluttering the UI and making a damaging first impression. This is a problem that goes back to 2006. Twenty years later, FedCM speaks directly to the NASCAR problem and solves it neatly within the Web platform.
There is an additional one-tap flow that doesn’t require that initial button click. Instead, the account picker is presented to the user by the browser itself when the page loads. So that’s two clicks to login to a new app for the first time instead of three.

FedCM is where the Web is heading for login, and I believe strongly that this will be the future of Atmospheric login too. On the current trajectory, the account picker enabled by FedCM will likely be compatible with the way OAuth works in atproto. So it appears likely that Atmospheric login will find first class treatment on the Web. Imagine a single account picker, shared across sites, that lists accounts on your self-hosted PDS, Bluesky hosted PDS, and Eurosky hosted PDS. Let’s go!

But there are still a few things they need to get right to serve use cases outside the major established players. And that is why we are lucky to have our community member Emelia Smith in the room, participating as an Invited Expert at the W3C backed by a Bluesky grant, to represent use cases motivated by decentralized identity.

Things are looking good for us there, but there are still several steps ahead. And these major shifts don’t happen overnight: it takes months and years for browser adoption to play out. But the Atmosyear is already in full swing. We can’t wait.

Atmosphere, today

If we can’t wait, then where should we place our focus right now? In my view we should be sending ourselves on a trajectory to take full advantage of the FedCM future when it arrives. And in the interim Web 2.0 is offering some great cues on how to give users a recognizable, low-friction, and continuous experience bouncing between apps in the Atmosphere.

There is no doubt that we need to do this in an Atmospheric way and working within our unique design constraints, so it probably wont be identical to the Google login button. But there is still plenty to be learned there. We have users knocking on our doors: let’s give them a best in class first impression of the Atmosphere and set them up for their next run-ins with us.

I believe there are really just two key components to set us on our way to Web future.

A recognizable login button. When users see it they know they can login with their Atmosphere account. And they will come to expect an Atmospheric experience once they’re in.
An account picker that feels like it comes with you across the Atmosphere. If a user already has an Atmosphere account, they should be no more than three clicks away from using your app once they discover it.

Two components—and, as ever, two dozen questions lurking behind them. How can this work technically? What is the trust story around a shared account picker? Where can account picker state live? What does the button say on it? If it needs to be recognizable, is there a logo on it too? How does the integration work for builders? After all, it can only work for users if it also works for builders.

On we go

While I have been chewing on this quite a bit, I certainly don’t claim to have all the answers, and there is a lot more for us to get into. In the upcoming diaries expect usable demos, technical designs, probably some feelings too. And let’s map this out together: this thread is now open for longer for comments and discussion. What do you think? Catch you for #2.