· Brittany Ellich  · 9 min read

On Atproto and Atmospheric Groups

I'm starting A Fresh Blog(tm), this time on Pckt. I wanted a dedicated space to post about development, atproto, and community thoughts, and a new space felt like the right place for it. Plus I wanted to get in on standard.site summer while it's still ongoing. Before I get into any of that, though, an introduction. As of a little over a month ago, I work at Bluesky! Before that I was a staff engineer at GitHub, and a long time before that I have a background in public health, which colors a lot ...

I'm starting A Fresh Blog(tm), this time on Pckt. I wanted a dedicated space to post about development, atproto, and community thoughts, and a new space felt like the right place for it. Plus I wanted to get in on standard.site summer while it's still ongoing.

Before I get into any of that, though, an introduction.

As of a little over a month ago, I work at Bluesky! Before that I was a staff engineer at GitHub, and a long time before that I have a background in public health, which colors a lot of the lens through which I look at software. At Bluesky I'm on the exploration team, where we're building Attie, a tool for using AI to help you build experiences leveraging the scale and freedom of the open social web.

I was part of the Atmosphere Community prior to working at Bluesky. I help run Atproto PDX, I built (probably too many) side projects on the protocol, and I've done talks about atproto at several meetups, conferences, and impromptu bar gatherings.

I really, really want to see atproto succeed. Enough so that I switched jobs to be able to focus on it full-time. Enough so that I spend many, many hours outside of my day job thinking about and building in this space, even when I spend most of my day job in it now, too. I have a lot of energy for this space that I want to spend on making atproto mainstream and successful in whatever small ways I can contribute.

I'm planning to still be involved in Atmosphere Community things whenever I have the bandwidth, and recently that has taken the shape of working on the Atmospheric Groups working group. I've already learned a ton from participating in the group, and I keep coming out of meetings with that group having things that I want to share. So I figured that I'd start a space separate from the Discourse forum to get my thoughts out and share them as we work through the complexities of making groups happen on atproto.

What you can expect in this blog: writing about building on atproto (either for work or for fun!), what I'm learning from folks in the community, notes from co-hosting a local atproto meetup, and probably some opinions about community and building healthy spaces on the internet, which has mattered to me for a long time and is a big part of why I'm here at all. Also, this post and all posts within this blog are my own opinions, not my employer’s.

So here it goes!

What is an Atmospheric Group

An Atmospheric Group is a group that can exist across multiple atproto apps. It is a group made up of many spaces across the Atmosphere. This is a concept that I started looking into several months ago, that I built an app to try and help define, and seems to have enough momentum that I think it may actually get off the ground soon.

This is particularly important now as we are approaching a time where the ability to form permissioned spaces on the atproto protocol is becoming a reality, which is a requirement for groups to have private spaces that still exist on the protocol.

I think that Atmospheric Groups are one of the most exciting upcoming components in the atproto space. They provide an on-ramp for people that are connected to others in person or online that might not already be in the Atmosphere. They provide a space away from the giant town square that is Bluesky for folks to exist, gather, and hold real conversations that might not play out the same in a public space (although Bluesky is also working on their own cozier spaces, too). They allow individuals to talk in a space with defined rules and group norms, reducing the impact of a “drive by effect” where folks can react to posts without understanding the context of the community in which they were posted. They also provide an opportunity for a consistent identity that exists on its own, beyond the confines of any one app. These are not "Discord" communities or "Subreddits", and they aren't even just "Bluesky Communities". They're not beholden to the confines of any one single application, because that's not how community works.

Even now when I'm part of a community online, the edges of that community often bleed outside of the main gathering app. Yes, we might have a Discord where we all chat, but we also have a shared cluster of folks on GoodReads to share what we're reading, and a shared Google Drive folder for resources we gather, and some folks that consistently have to remember their Elfster login every year when the annual Secret Santa rolls around. The group still exists as an entity across every one of those apps, and always has to re-find each other and re-establish the rules and hierarchy of the group within each space. What if they didn't have to? What if the boundaries of "who is in the group and who is out of the group?” and “What are the group norms?” and “How do we kick someone out who is being a jerk?" could be defined in a way that it could be reusable across every app the group exists in?

There's a second problem here too, one that Daniel Holmgren laid out well in the working group discussion: groups today have to choose between a space they genuinely own (a standalone forum with its own logins, its own notifications, and its own app, divorced from everyone's wider social lives) and a convenient platform like Discord or Facebook Groups, where setup is easy but real ownership and customization are off the table. When the group's data is shared through something like atproto, that tradeoff dissolves. The same group can show up inside an app the members already use and inside a fully custom home base the group owns, and it's natively the same group in both places.

In the world of walled gardens on traditional platforms, this is nearly impossible. Those platforms own your group, and making meaningful changes to the structure of it means a complicated migration process for all group members. But in the Atmosphere, it is possible. The group, whether that’s a friend group, an organization, or a community, owns its identity, governance, and data across every space.

That's the promise of Atmospheric Groups and why I think it's important for them to exist.

I don't think that every community within the Atmosphere needs to be an Atmospheric Group. Many of them will make sense to remain within a single app and not extend outside of it. But if we want Atmospheric Groups to happen, we need a standardized way to approach them so that app developers can integrate them.

As it turns out, standardizing something like that is slow work in a decentralized space. We aren't colocated, we don't work for the same company, and everyone within the working group has different reasons for being there and levels of bandwidth to give to it. We constantly risk talking ourselves into (or out of) everything forever and never getting anything done, or rushing it and not getting the right amount of buy-in and voices.

That said, I think that we are coalescing around a few important points that will allow the creation of Atmospheric Groups. The first of which is what defines a group? A few traits keep coming up in the working group discussions: a shared identity that persists across apps, some notion of membership (who's in the group and who's out), and some form of governance ("this is how we do things here"). Not every group will care equally about all of these, but they're a useful shape to start from.

The piece with the firmest agreement so far is identity: an Atmospheric Group is an account with its own DID. That means it can have a custom domain, it can exist on a PDS and even migrate between PDSes.

There are many other things I want to see out of Atmospheric Groups. How do we moderate across multiple apps, and what does it even mean to moderate an Atmospheric Group? How do we make it easy for app developers to integrate Atmospheric Groups into their apps? How do we allow democratic structures to exist such that we don't cede all control to whoever happened to make the group, regardless of how that group evolves and changes over time?

I'm very hopeful about the direction we are heading so far. My preference with work like this is to gather feedback, build a proof of concept, and see how it works, adjusting as we go. That's the role OpenSocial has been playing and I'm planning to continue to invest time in it as permissioned spaces are released. Not that I intend for OpenSocial to be the standard, but it is a proof of concept to help inform my suggestion of what the standard may be, based on what we’re learning in the working group (likely actually owned under a shared lexicon instead of an app-specific one).

It's worth saying plainly that everything in this post is my own lens on Atmospheric Groups, and isn't itself the standard. Viewing software from multiple lenses is important, and getting many voices as input is also important. This is one view among many, and I hope you'll go read the others!

The folks building in this space

One of the biggest reasons I'm hopeful is the people in the room. The working group isn't a bunch of people theorizing about what communities could someday be. These are folks that are already building in this space, and who are passionate enough about communities to dedicate their time to finding common ground and a shared understanding of Atmospheric Groups. Some of the people and projects you should know about:

The folks working on Smoke Signal, Roundabout at New_ Public, Roomy, Acorn at Blacksky, Northsky, Furryli.st, Habitat, OpenMeet, Gifthood, and atmosphere.community

Ms Boba and Baldemoto, who have been running the working group from early on

Emelia, who is an independent decentralized web developer, as well as an incredible reference, resource, and explainer of all things technical

The contributors to Lexicon Community

Daniel Holmgren, Devin Ivy, and Paul Frazee from Bluesky

And many others!

So that's the beginning. There's much more to it that I'm sure I'll be writing over time. If you're interested in getting involved, check out the working group on Discourse or keep an eye on events related to Atmospheric Groups from the atprotocol.dev account on atmosphere.community, where we'll continue to share future meetings.

📌 Want to hear more from me? Subscribe to The Balanced Engineer newsletter!

Back to Blog

Related Posts

View All Posts »

Why I'm betting on ATProto (and why you should, too)

Social media was supposed to connect us, but most of it has turned into ads, division, and loneliness. I'm betting on ATProto as a way to fix that, and not just for developers. Whether you're a scientist, journalist, or just someone who wants the internet to feel human again, I think ATProto matters for you too.

Representing groups in ATProto

I wanted to add book clubs to my GoodReads-like app (Collective), but ATProto doesn't have a standard way to handle shared group resources yet. So I'm building opensocial.community—a separate service that manages groups independently from any single app. This means the same book club could potentially work across multiple apps (imagine your book club having both a reading list in Collective AND a discussion forum in another app), and groups can migrate between providers if needed. It's probably over-engineered for my use case, but might help other ATProto developers building community features.

Build the thing you wish to see in the world

Build the thing you wish to see in the world

For most of my career, I've been confusing building products with building businesses—and that confusion kept me from pursuing a lot of ideas. Two weeks off helped me realize that not everything needs to be a startup, and some of the best things we build are the ones we build just because we want them to exist.