In the very early days of the atmosphere we only had Smoke Signal. Made by it clearly demonstrated how events could work on the atmosphere, complete with an open events lexicon for subsequent apps to hop on to.
Whereas Nick had replicated the essence of Luma, needed a Meetup alternative and built one accordingly. Since there were no private spaces on the horizon back in 2025, OpenMeet started out very bespoke, gradually aligning more closely with the AT protocol as it matured.
Then came atmo.rsvp by flo-bit.dev. Another Luma-like, but with more of a design-first approach1; an instant hit among the atproto nerds.
For the past year I've been intermittently checking in with all the aforementioned project owners to advocate for a more intentionally coordinated events stack in the atmosphere.
Everyone in the bunch has been positively inclined since the start, but these things take time. The hardest thing about making this sort of collaboration happen is deciding whose codebase to rally around, since each developer is naturally most comfortable and attached to their own work which they know intimately.
Longer story short though, convergence is now happening! Smoke Signal has been simplified to a read-only events browser, deferring to atmo.rsvp and OpenMeet for actual scheduling.
As for OpenMeet, Tom has very graciously agreed to incrementally transition the very sizable amount of work he put into OpenMeet over to atmo.rsvp (or atmo-events as the code repo is called), essentially merging the two apps together.
It's a massive win-win: OpenMeet gets a more streamlined interface while atmo-events gets extended with a bunch of Meetup-like organizational features. openmeet.net may continue operations to service its existing userbase, but as another instance of atmo-events as opposed to a separately maintained codebase.
Tom and Florian have already been co-authoring atmo-events and contrail (its appview) for several months. Now that these are no longer single-person projects those repos will likely be moved into organizational management2 to further facilitate communal ownership of the canonical atmospheric events stack.
I see this partnership as emblematic of the "Atmospheric Stacks" model we're seeing organically take shape for every major application archetype.
On Atmospheric Stacks…
Or, how we can supplant Substack and take back the stack, together as an ecosystem!
Make events better for everyone
atmo-events isn't a single website, it's atmospheric-events-in-a-box. Events are an inherently local phenomenon and as such they tend to work best as bespoke websites rooted in place, like the Danish activist calendar dukop.dk .
What local organizers don't want is having to choose between several small indie projects with uncertain futures, all seemingly trying to solve the same problems but in subtly different ways, making it very hard to pick the Right One to get the job done.
By building events as a community-powered stack we can rally around the essential affordances for events organizing and leave the finer details to the localized implementations.
Seeing the potential of a larger collaborative effort, a handful other developers have already done their part:
added Topics.
added "find a time" scheduling (pending).
added email notifications (pending).
added Atmosphere Tickets (pending).
Should you feel inspired by the joint effort, let Tom be your guide:
The way to build most effectively for organizers is to get more organized in our tech-making. It's 2026 and we have some exciting new tools at our disposal that make development faster, but to realize our grandest ambitions there's still no substitute for team work.
Larger collaborations of this kind is a clear sign of a maturing ecosystem that has graduated from the maverick prototyping stage to the kind of real-world problem solving only tractable by coordinated groups of shared purpose.
Building for Organizers
The most enduring social networks aren’t the prettiest or the most addictive – it’s the ones that empower organizers.