When I wrote "On an Atmosphere OS" a few weeks ago, the response was much warmer than I expected. The most useful feedback came from :

Astra ⭐'s avatar
3w

my room-temperature take is that you don't need a custom ROM to do this the same end result can be accomplished on stock android with an on-device "account vault" style app using a common API to communicate with other apps that support that SSO schema, no system access or custom ROM required

And she's completely right! We don't need a fork of GrapheneOS, or Android, or even a new Linux fork (even if someone is paying for this one), or anything else for that matter. The building blocks already exist to let an Atmosphere account act as a device-level identity on stock Android, using Android AccountManager (docs) and Credential Manager (docs).

Instead of requiring a fork of Android, we can offer an apk that users install, sign in to their Atmosphere account through OAuth, and then they can see their account in their phone's settings screen under Accounts and backup -> Manage accounts.

Android Settings Manage account screen showing my Atmosphere account @scottlanoue.com

Currently that doesn't let them do anything special, but if a user has a fork of one of their favorite atproto apps, they could add a small check at the login step that requests an Atmosphere credential through Credential Manager. If there's an Atmosphere account currently logged in, then the user can be presented with the option to use that account rather than having to re-type their password.

The user-facing experience is near-identical to what I showed previously (here), except now we're on stock Android 17 -- no OS fork required!

This work ties in surprisingly nicely with FedCM issue #817. invited me to present the earlier GrapheneOS version of this demo during the W3C FedID meeting on August 25, 2026. Overall the reception was relatively positive, with most of the conversation centering around how this relates to passkeys and verifiable credentials, and whether it helps with FedCM’s account “cold start” problem. I think these approaches can coexist and complement one another. During the discussion, asked whether it could work on stock Android, which led to the Android 17 prototype shown above.

However, this clearly shows that there's sustained interest in this proof of concept, and I don't want to hoard this work. I will publish the Atmosphere credential provider source to tangled later this week (please hold me accountable!). The initial sign-in flow is:

  • Ask user for Atmosphere login

  • Complete OAuth

  • Store the device session encrypted inside the provider app

Then when a user installs and opens an atproto native app, the flow will be:

  • Ask user if they want to use their on-device account

  • Approve a new, app-specific OAuth session

  • Voilà! You are now inside your favorite app 🎉

I won't be releasing a compiled version and I do not suggest installing the application, as it is experimental and a proof of concept. But YOLO, so don't let me stop you.

Of course, an account layer isn't that interesting without something to use it for.

Can we talk about the mail, please?

Since Bluesky and graciously blessed us with the Spaces alpha, including a hosted PDS (icymi), I've been steadily working towards personal inboxes with comail. Think gmail, but now using your atmosphere account and storing data inside of your PDS. Really happy to share that I was able to prove a working prototype that can store and reconstruct a real email from a Space inside of the Alpha PDS:

Scooty's avatar
2d

Yoooo, it works!! That's an email stored in my Space on Bluesky's alpha PDS, then rendered in Comail's fork of Bulwark! Can't wait to share it with you sooooon

Screenshot comparing the same test email in Comail and Bluesky’s Spaces alpha PDS. On the left, Comail’s Bulwark interface shows the message and its raw source, with a comail-pds-sha256 identifier highlighted. On the right, PDSls shows the corresponding email.atmos.message record in my mailbox Space, with the matching logical message ID highlighted. The Comail inbox below shows the email titled “Test.”

The Spaces alpha provides access control, not confidentiality, so this is not ready for any production mail. You'll be able to test it soon™️, for now be sure to sign up for the waitlist here.

On calling

Scooty's avatar
3w

Continuing down the path toward a fully independent phone... what about the actual phone part? 🎬 calling an atproto handle

Screen recording of Freeq on a Mac beside a mirrored GrapheneOS Pixel. The account @scottlanoue.com (on the freeq client) calls @atmosphere.beer (on the pxiel phone); the Pixel rings, answers through its phone interface, and green outlines in Freeq show each participant speaking during the two-way audio call. After the call is over, there is now an entry in the Android phone's call history showing the call with @scottlanoue.com

Email isn't the only core communications platform that can be solved via atproto. I used 's AV Call Protocol to prove that we can make phone calls on a device that has logged in through the same Atmosphere credentials provider. There's a lot of polish and work that needs to be done before this can be shared, so keep an eye out for updates on tangled.

Your Atmosphere account is much more than a Bluesky account, and access controlled Spaces will really show the power of the PDS to the network. We've proven each piece separately in that we can put our Atmosphere account inside the Settings of a stock Android device, mail and groupware connected to that account, a real email stored in a PDS Space, and calls can reach an atproto handle. Now the task is to assemble these pieces into one cohesive unit, but we don't need another (OS) fork.