What is an atmospheric group/community?

Howdy friends! If we haven’t met, my name is Brittany :slight_smile: I’m a passionate ATproto advocate, past Atmosphereconf speaker from this year, builder of OpenSocial, and as of just a couple weeks ago an employee at Bluesky! I can’t think of a better or more exciting place to be spending my time and engineering expertise right now than on ATProto.

One of the things I’m most excited about unlocking in the ATProto space is groups and communities that can live across multiple ATProto applications. My personal DID/repo follows me around everywhere in the Atmosphere, so why can’t I interact with my community identity across the entire Atmosphere, too?? I think this is a very compelling unlock for just what kinds of cool applications can be built on ATProto.

After this message last week we pulled together a meeting of folks that we know are already working in this space to get some alignment on where things might intersect. We got an awesome group of folks together from multiple applications that are interested in this effort, including Blacksky with Acorn, Roundabout, Habitat, Roomy, Bluesky, and the folks that have done an excellent job leading the working group so far, @baldemo.to and @essentialrandom.bsky.social .

One big thing we agreed on: building an interoperable solution for this likely means we’ll need to share a data contract, similar to standard.site, so it’d be good to discuss what that actually looks like! We want to make sure that this is an effort led by the ATProto community as a whole, because communities can mean a lot of different things to different people! The first topic of this conversation: What is an atmospheric group/community?

It would be good to get some alignment on that, with some examples, so that we are operating from a shared understanding before moving into the implementation details :grinning_face_with_smiling_eyes: So with that, please provide your thoughts on that in the comments! I’ll share mine there, too, to not take up any more space here. You’re welcome to participate whether or not you attended of course, and there are no wrong answers here :grin: it’d be great to understand what you view as a group or community in the Atmosphere and what sorts of examples we have to work from as we get into defining a shared data contract!

12 Likes

Here’s what I think of for atmospheric groups.

Group is both more vague and more inclusive of different entities (like organizations that may not recognize themselves as a “community”).

These are groups whose identity can exist across multiple ATProto applications but have a shared identity that can be curated over time.

Examples

  • atmosphere.community: This is a community that encompasses the many local meetups for ATProto and has its own website, as well as an ability through OpenSocial to share blog posts and events from sub-communities, such as…
  • pdx.atproto.camp: ATProto PDX, the local community meetup for Portland, Oregon! This is also an atmospheric group in my opinion. It has a Bluesky presence as well as a presence through atmosphere.community and opensocial.community!
  • overcommitted.dev: This is my book club/podcast/developer group I’m a part of! We have a Bluesky presence, our own website (that will soon be standard.site enabled :crossed_fingers: ) AND book clubs managed through Collective!

All of these things have an identity, some sort of concept around “membership”, and also a form of governance or stating “this is how we do things here”.

4 Likes

Schweet, thanks for making the post Brittany & nice getting some face time with folks today!

I’ll try & describe what I mean when I say “atmospheric community” while trying not to get too technical or lost in the details.

Basically, I see atmospheric communities as cross-modality, cross-app communities that can have a web presence of their own as well.

One of the hard things with communities on the web today is that you have to make the difficult decision between two options:

  • having a genuinely community-owned space that is divorced from the rest of your community members’ online social lives (separate login, notifications, application, etc)
  • using a platform (fb groups, reddit, discord, etc) which grants ease of use, but no sense of ownership or customization

Atmospheric communities get around this problem because the same data can show up in both contexts. A community can surface in platforms that access community data (Bluesky for instance) as well as in custom-built community platforms that are fully expressive & owned by a community.

Often this problem is even harder because communities aren’t just on one platform. They’re scattered across a bunch of different platforms. As in the same “community” in some sense, but it has to regroup on each different platform that it’s using: discord, reddit, discourse, signal, etc. These platforms all get stitched together in various ad hoc ways (even if just links between the various spaces). However they’re not natively “the same community”.

Atmospheric communities solve this problem in the same way, since you have a persistent community identity across modalities. You still get to use each modality! And when using the app for each modality, you see content from all communities that you’re in in that modality. But you also have the home base of the community that shows you content from all modalities in that community.

To illustrate how this might look in the Bluesky app & with the communities feature that Alex teased:

  • Bluesky “cafes” are permissioned community spaces of Bluesky-style microblogging content (we don’t know what we’re calling them yet, but I kinda liked this term & it’s helpful to draw the distinction from communities/spaces/groups/etc) .
  • When you create a cafe, you give it a handle (say you call it protocol-nerds.bsky.social). When you do so, Bluesky deploys a landing page for you at that domain
  • That domain is now the community’s presence on the open web.
  • Administrators of the community can create an application that you log into at that site to view content from that community across different modalities. This can be fully customized/personalized according to the community’s preference
  • When you login at protocol-nerds.bsky.social you can read and interact with all the data from the Bluesky cafe. If you post into it, then it shows up in the Bluesky app (and vice versa).
  • The community might want to add an events calendar, in which case it would add in a community.lexicon.calendar.something space along with UI for interacting with it. All of those events will show up when you login to smokesignal or atmo.rsvp (along with events from other communities you’re in)! They’ll also show up when you login it to protocol-nerds.bsky.social.
  • The community can continue to add additional modalities over time. Each of these modalities shows up in the modality-specific app. But they’re also all accessible in one place when logging into protocol-nerds.bsky.social
  • When an admin of the community logs into protocol-nerds.bsky.social, they can customize the space, assign roles & mods, adjust membership logic etc.
  • The community can migrate off Bluesky infrastructure and self-host (or use another community hosting platform). This should not affect how any of the data shows up in any apps or how users interact with the community (similar to how account migration of user accounts is basically transparent)
  • Similarly communities created in some totally different manner or through some totally different framework should be able to show up as Bluesky “cafes” if they create the proper space (e.g. app.bsky.cafe).
6 Likes

A group or community has its own atproto account, and has one or more member lists associated. It shares access to one or more lexicon types.

7 Likes

In my head right now, the most important defining characteristics of a community are:

  • a recognizable identity
  • a boundary of some sort differentiating what is inside from what is outside
  • some means of authority over that boundary, encompassing both what is allowed to go in as well as what is allowed to come out
  • usually some internal boundaries that can divide things inside the community into sub-groups

So, trying to keep things from a more user-facing perspective.

A Recognizable Identity

The community should have a web handle, just like Atmosphere user accounts, so that I can mention / find it in any app if I know it’s handle.

I think usually a community shoud have its handle be a visitable website, too, so that I instantly know where to go to get more info about that community.

For example for Muni Town we have a @muni.town Atmosphere account, and we have a ( work-in-progress ) https://muni.town site made with Blento.

The community should also have a standardized “profile” of sorts so that:

  • Public communities can be discovered by indexing the network.
  • I can search for communities that I might be interested in based on their descriptions, tags, location or similar elements.
  • All my apps know how to show me the basic info about any given community that I’m allowed to see.

Clear Boundaries

Similar to knowing that a post is by a specific user, I need to be able to know when some content is in a community.

This doesn’t always mean authored by the community, but it does mean, at the very least, included in the community somehow.

Again, this is similar to a user account. A re-post doesn’t represent something the user wrote, but I know that the user decided to reference that content under their own account.

This also applies to subgroups in the community. It can make a big difference to me whether a post is included in the “team members” subgroup compared to in the “public forum” subgroup.

Any content that I see in a community or one of its subgroups is there because the community or subgroup allowed it to be there.

A Means of Authority

The community boundaries are meaningful because they have some authority behind them, similar to a user’s posts carrying authority because they wrote ( or at lest authorized someone else to write ) under their own identity.

Different communities may have totally different authority mechanism. Some communities may have one person who decides with absolute power what is included in the community. Others may have some democratic process or have delegated owners for particular subgroups, etc.

As a user, there are a lot of times I actually don’t need to care about the details of the way authority is managed for a community. It may be enough for me to merely see or contribute within the communities and subgroups that I have access to.

The most common interaction a user will probably have with the authority will be to join a community or subgroup.

It would be best if there was some standardized way to go about joining a community / group, or at least finding out where to go to do so. That way, if I find an interesting community through some community-disocovery app, the discovery app will know how to help me join, or send me to a place where I can apply to join.

Community Managers

The people who create or manage communities will have to be much more involved with the means of authority. They will need to be able to create a community, possibly set up roles and add members with different levels of access, configure who is allowed to join, whether the community is public or private, etc.

The levels of complication here can anywhere from very simple to extremely complex.

Different community management apps should be allowed to exist so that they each may give community managers different kinds of abilities as far as creating and delegating access to the community and its subgroups.

Regardless of the community management app that is being used, all of the other non-management apps should still be able to recognize the community and its boundaries, even if it has no knowledge of the nuances involved in the means of authority.

5 Likes

Fully agree with all of these definitions :smiling_face: Especially this:

As a user, there are a lot of times I actually don’t need to care about the details of the way authority is managed for a community.

I feel like we are circling a lot of requirements for managing groups but it would be quite nice if they’re very easy for both apps and users to actually interact with. But I guess that’s the whole purpose of defining a shared contract anyway :joy:

5 Likes

Thanks for making this Brittany!

I think there is a real distinction to be made here that points to 2 very different considerations/use cases for the infrastructure. This is the typology I’ve settled on:

  • A group is a set of people that willingly convene, for any reason. Online, these are Discord servers, subreddits, Facebook groups, etc.
  • A community is a looser, emergent social construct, where individuals are united by a shared identity built from common values, experiences, and/or affinities. The identity itself acts as a social signal others evaluate. Think fandoms, the Black community, the scientific community, etc.

Communities can emerge online and offline. Online, a group can take on a shared identity that carries social meaning to the people within it , creating a community (e.g. Blacksky).

Regardless of how they emerge, a community lasts as long as people keep identifying with it, and no one person can fully control what it is or where it goes.

This distinction between communities and groups is meaningful; while in groups, governance is often real and actionable, within communities, there is almost always no one “governance” that dictates behavior.

That independence itself is both indispensible to the nature of communities, and what makes communities fragile online in the first place. Online, the community naturally gathers as a group, a lossy projection of the community. To exist as a group, it has to gain two things communities never had: a hard membership boundary (in/out) and a governance that can enforce the terms of belonging.

For example: individuals within the furry community can’t, by themselves. dictate how the furry community behaves. However, a furry convention (i.e. group) can set rules and enforce them on the spot.

This is simply temporary for conventions and conferences. But online, it’s a necessity by nature. When this happens, a fundamental tension arises: groups manufacture authority that never existed. The group acts not as a neutral container, but as a transfer of power to a gatekeeper. For both established communities (e.g. furries) and ones born online (e.g. Blacksky), that raises an unavoidable question that has no clean answer: who legitimately holds that gatekeeping power?

This problem scales directly with size.

  • Small groups and communities run because everyone knows everyone
  • Large groups operate through structural mechanisms (e.g. businesses, mutual aid)
  • Large communities operate on network-level dynamics

Projecting larger communities into the same structure as groups and small communities is a category error. It flattens these vital dynamics and forces members into that same power structure.

So what does this mean for atmospheric communities? Brittany already pointed at the structure:

I’d argue those are three properties should be separable:

  • The community identity: the emergent, self-claimed cheap social signal that lives with the people who hold it (declared belonging);
  • The Membership boundary: who the community vouches for (the membership list/gatekeeping function);
  • The social space(s): the governed contexts where communities live and social norms are enforced (enacted belonging)

Collapsing these into a single “group” entity bakes in a gatekeeper-into-landlord problem. By keeping these 3 properties separate, the community and its identity aren’t captured by whoever happens to operate a boundary or a space.

This is similar to what @zicklag.dev proposed, although with an additional separation between who’s allowed in (membership) and what content is in a space (inclusion). It’s the difference between vouching for a user (a two-way label) and governing what shows up. By separating these two, gating authority for both becomes an explicit, contestable choice rather than an accident of whoever got there first.

3 Likes

I may have mentioned that I’ve spent a lot of time reading and thinking about community, so I’ll point at two books on this I really like before I regurgitate their wisdom. :joy: I make no claim to my claims.


The issue I keep running into is that “community” is a very colloquial word: people use it to mean a group, an identity, a gathering place, a support network, an audience, a membership boundary, a governed space, a vibe, a set of rituals, a social graph, etc. These things often overlap, but they are not the same thing.

This is where people start talking past each other. We hear “building for communities,” and one person imagines people who have agreed to be in the same place; another is talking about an identity people claim; another is focused on who gets access to a space; then yet another centers the actual feeling of belonging and mutual care, and wonders why everyone else is treating that as secondary.

Some more examples I had written, quoted so you can skip them, or read as food for thoughts:

Communities exist across too many axes, even just inside the atmosphere. You can have communities that form around a single event, seasonal communities, communities around fundamental identities, communities around limited shared experiences like going to the same school, communities trying to accomplish a specific goal, communities that meet regularly, communities where people only appear when they need help, and communities around long-term interests or very tiny fragments of an interest.

Fanworks fandom is a good example of how messy this gets. Someone may at the same time be part of the “fanfiction community,” a specific fandom community, the shipping community inside that fandom, a specific pairing community, a specific interpretation of that pairing, and then maybe a group that got in way too deep and now the pairing exists in a world with no relationship to the original story. Some of those even get book deals, starting the cycle over again! The distinctions may look absurd from the outside, but they are very meaningful from the inside: wars have been fought across these lines, doxxing has happened, countless posts have been created. These groups may talk about the same characters, share some people, share some content, and occasionally want to come together for events like fic exchanges. But that does not mean you can or should collapse them into the same community.

The very beginning of Building Brand Communities (one of the books I mentioned) makes one distinction I find especially useful: a group can share values, identity, and even moral prescriptions without necessarily being a community.

A community, in their framing, requires mutual concern for one another. A list of people with the same background or interest may be a group, but it does not become a community just because the list exists. There is a group of people building for ATProto, but only some of us are here on atprotocol.community, slowly beginning to build relationships with each other.

We don’t have to adopt that exact definition, and it’s not the only one—but I come back to it because it reminds me of why a precise, exhaustive definition of “community” is a fool’s errand.

So the question for me is: how do we do this work if none of us will ever fully define “community”?

The Art of Community has a list (:backhand_index_pointing_down:) that I’ve always taken as a hint toward primitives. Building Brand Communities also distinguishes visitors, participants, and members on top: participation is not automatically membership, and membership usually involves crossing some kind of boundary.

These line up with what others have already said here: @brittanyellich.com pointed at identity, membership, and governance/norms. @zicklag.dev broke out identity, boundaries, authority, and sub-boundaries. @baldemo.to separated community identity, membership boundaries, and social spaces.

Once again, I think people here have more answers than they feel they do—the answers just seem small next to the scale of the space. But we aren’t going to solve “the space,” so we should build in a way that frees us from trying.

Instead of modeling “the community” as one ultimate object, we should focus (as intuition seems to be leading us!) on composable primitives that communities, groups, identities, organizations, and spaces can arrange and rearrange in different ways: identity, participants, members, membership claims, boundaries, roles, spaces, rituals, stories, symbols, inner rings, permissions, and governance/authority.

Getting the composability story right helps with edge cases—let someone else show up with their very particular, very niche needs, and take building a solution for it completely out of our hands. It also speaks to @baldemo.to’s worry about scale: if we’re clear about the separation between identity and governance, between participation and membership, large communities can access the primitives that make sense to them without anyone being able to claim authority.

This last category (the very large, very amorphous community) is a problem space I feel may be currently under-explored. It may be worth having specific discussions about what those communities need, so that we can make sure the primitives we build are not incompatible with them. I definitely have some things I would like to build for the larger fandom community that don’t map neatly into what the current projects seem focused on.

tl;dr: neither the protocol nor us can decide what an atmospheric community is. What counts as a community is unknowable: attempts to pin it down are doomed to end up in fights over competing (and valid) needs. We can only break the problem down, understand its edges, and create pieces that are legible and useful enough, so everyone can come build different, overlapping, deeply weird, and actually useful definitions and experiences on top.

6 Likes

After writing all of that, as I run to bed, one more thought: maybe the real question that needs answering here is not “what is an atmospheric community?” but “which type of atmospheric community are we building for right now?”

Framing this effort around specific, well-defined use cases that are currently in scope, rather than a general idea of “community”, can be both more tractable and more honest. One thing is to say we’re doing “communities in the atmosphere”, another is saying we’re doing “this particular slice of them” while being upfront, with ourselves and others, that it’s only that slice.

I don’t think this goes against what I said: composability is still the way through. And being clear about our slice doesn’t mean ignoring the other kinds of communities. That is how you build yourself into a corner.

Rather, this is about making sure people don’t end up talking past each other: if we can be honest and truthful about what we are and aren’t building for, we can actually see where people’s needs diverge and build something that doesn’t overstep them.

The alternative—pretending we all care about all types of communities equally—is worse: it takes away our ability to say “that specific problem is not ours to solve, but here’s how we’ll avoid making it worse,” until the need surfaces as a fight instead of a conversation.

And with this…good night! (she says, at 5:30AM) :sleeping_face:

4 Likes

I love all the discussion here. @essentialrandom.bsky.social brings up some excellent points: we all have very different ideas of what a community is, and they’re probably all correct in their own way. Hinging the work of communities in the atmosphere on a definition is probably not going to get us very far :grin:

I’m imagining that much of the discussions in this discourse will ultimately serve as starting points for documentation written on how to integrate with atmospheric communities, and we will have to be careful about not being overly prescriptive in either the constraints imposed by the design or the ultimate description of what a community is when the docs are written.

2 Likes

Thank you @essentialrandom.bsky.social, this is a great writeup!

I agree completely. I think it’s important both to define the kinds of groups and communities we’re serving and to develop ways to (at least try to) assess whether what we’re standardizing actually serves them.

To that end: before we finalize any standards, I think the first deliverable should be a set of prototypical groups and communities spanning the range we want to serve. For each, we’d capture some key aspects, such as:

  • scale
  • membership/identity dynamics
  • how membership and governance work, if it exists
  • failure states
  • how they exist and operate within and across social media services
  • etc.

This way, we can hold any proposed standard up against each case and feel out whether and how it could serve them well or fail them.

The list wouldn’t be (and shouldn’t be) exhaustive, but it should strike a balance between breadth and what standards can realistically serve.

If there’s appetite for it, I’d be happy to make a first pass for people to pick apart and add to!

2 Likes

If there’s appetite for it, I’d be happy to make a first pass for people to pick apart and add to!

This sounds great! Do you want to make a Google doc for it? I’ve got a list I can help contribute to it :grinning_face_with_smiling_eyes:

1 Like

Yeah, definitely agree with this!

Yeah, I’m realizing that there is a lot of value to having “test cases” even if they are just thought experiments or reference use-cases.

Would be happy to add some examples of what we’re imagining for Roomy communities to a list.

We could potentially use a wiki topic here on the forum, but I don’t really care where it goes.

1 Like

That would be great! We should also have a specific thread for it once you’ve made it so we can hash out examples.

Second this distinction, and I think this working group would be most accurately named the “Group Spaces WG”.

Every community is made up of one or more groups of people. However not every group is a community. As such, the protocol primitive we’re defining here is first and foremost group spaces.

4 Likes

Love reading the thoughts here, thanks @brittanyellich.com.

We have now around 800 organizations with a group account using the Certified Group Service (CGS): GitHub - hypercerts-org/certified-group-service: Enable groups to manage an ATProto PDS · GitHub and Certified Group Service (CGS) - Hypercerts Documentation

Our use case is that regenerative land projects that are crowdfunding on maearth.com have multiple users that need different permissions to write into a shared repo, e.g. a volunteer posting pictures of a tree planting day shouldn’t be allowed to delete records.

If this architecture also works for other use cases that are discussed here, we are happy to contribute in whatever way that is useful.

3 Likes

Hey @holke.xyz the draft spec for permissioned data is here

It uses regular accounts without a special PDS to manage group data. You should get your team to review if you’d like to be compatible in the future.

1 Like

Hi! This is awesome :grin: I think that the Certified Group Service likely fits into the category of “group management apps”, which is exactly what we are trying to find a standard around! That is if the goal is allowing those groups to have enforced rules and identity across multiple ATProto apps.

We’ve got a proposal that we are working on in this doc and seem to be coalescing around the ideas of “group discovery” (how do we know this is a group and how do we find them) and “group management” (how to join, etc) as the logical places of standardization, and we are building these with permissioned spaces in mind.

Are you the best contact to get involved? Wanna DM me your email (or the email of whomever is interested from your team) and I can get them added to future meetings? I’m personally hoping to have a group prototype working with OpenSocial on top of permissioned spaces with whatever standard we end up with (or as close as we get to one) by the end of July, fyi, in terms of timing :grin:

1 Like

great discussions, thx :folded_hands:

Context: building Barazo, a forum AppView on atproto (a Discourse/Flarum alternative). Pre-launch, but spent a while on this topic, so here’s a few notes from my side. Built this with minimal community/group features being available at the time (Q1 this year) so the workarounds I used might not always be the best solution :sweat_smile:

A forum as a test case. If collecting concrete cases to check the standard against (baldemo’s suggestion), imho the classic forum is a useful one: For many people it will have a recognizable identity, sub-groups (categories), roles and governance, optional hard membership (as most forums are public-read, gated-write), and a clear inside/outside boundary. So like baldemo’s group/community split: bounded like a Discord server, but with the open, shared-identity feel of a fandom, so primitives have to assemble it either way.

Infra gap of “a group has its own account.” I also pretty much started with bmann’s minimal definition: a community as its own atproto account with member lists, content linked via wrappers (close to Nick Gs’ community-manager pattern). The blocker here is service-to-repo write delegation, some way for the community’s service to write membership proofs and wrappers into the community repo on members’ behalf. AFAIK atproto has no standard for this yet? Whatever the WG ships, I’d suggest making this dependency explicit: who writes to the group repo, and with what authority?

So in Barazo, the community DID is an identity anchor, not a content repo. Every topic/ reply/ reaction/ vote is written to the member’s own repo + tagged with the community DID; community config lives in the AppView database. There’s no membership record at all: participation is implicit, derivable from the firehose because every record a member writes carries the community DID. It’s buildable on today’s primitives without waiting on new infra, at the cost of AppView-level moderation rather than protocol-level (the AppView can hide content, but can’t delete it from a member’s repo). I also kept community config out of the operator’s personal repo: if the operator leaves or deletes it, the community shouldn’t go with it. So “the group’s data lives in the group’s repo” only helps once the group has a durable, independently-owned repo, which loops back to the identity primitive.

One caveat: all of this is public-read. Everything above assumes content is public records in the member’s repo. Fine for most parts of a classic forum, but mostly falls apart for private groups: the records are world-readable, and implicit membership leaks who-participated-where (anyone reading a member’s PDS sees it). When I built this there was no permissioned data to lean on, roughly what holke’s case and the permissioned-data proposal taht Boris linked are about? So I’d treat private groups as a separate shape: the public-record + implicit-membership approach above probably doesn’t carry over, and worth being explicit in scoping whether the standard targets public communities, private groups, or both. I bet @brittanyellich.com already has loads of thoughts on private groups :slight_smile:

Where to put community context. Do content records reference their community, or stay pure with wrappers supplying context? I put the community DID on every topic, reply, reaction, and vote so firehose consumers can route without resolving references (a reaction can arrive before the post it targets). Nick’s wrapper model keeps content pure. Both work, but they’re not interchangeable, and downstream indexers need to know which the standard assumes.

Membership as a verifiable claim, not a list. I’d argue for membership as a CID-verifiable attestation (the community attests it accepted the member) rather than a list entry. Otherwise “who’s in” isn’t checkable by a third party, which is most of what makes it portable across apps.

Happy to share more. Mapped existing atproto lexicons across the community/forum/reaction space and would gladly bring the forum perspective into the WG. The composable-primitives framing (@essentialrandom.bsky.social) matches what I’ve found: no single “community object,” there’s identity, boundaries, roles, and spaces that forums, chat, and fandoms arrange differently.

3 Likes