The last few weeks have been a busy stretch across the Open Social codebase. I shipped improvements to federated authentication, community structure, performance, and developer experience across all three repos: open-social (the backend), open-social-web (the web client), and open-landing (marketing and docs).

Here's a recap of what changed, why it matters, and where things are headed next.

Federation, identity, and auth

A big focus this month was making Open Social a better citizen of the ATProto network. Previously, the OAuth flow assumed a single auth server. With open-social#49, you can now sign in using any personal data server, not just the default one. open-social#62 reinforces that by using OAuthResolver to dynamically discover the right auth server for community app-password logins. On the landing site, open-landing@03a2e58 tightens the OAuth scopes requested so users only grant what's actually needed.

Huge shoutout to Emelia for all of her help with the OAuth work. Federation auth is tricky and her guidance made a real difference in getting this right.

DID resolution is on the hot path for almost every authenticated request, so it got real attention too. open-social#56 swaps the hand-rolled resolver for the official @atproto/identity library — less code, more correct, and aligned with the rest of the ecosystem. open-social#61 adds a PostgreSQL-backed cache so DIDs aren't being re-resolved on every cold start or across instances. The net effect: snappier auth, less load on upstream PDSes, and a more resilient login experience.

On top of that, a handful of paper cuts got fixed. open-social#63 (and its precursor #46) fixes a bug where valid API keys were rejected when more than one app was registered. open-social#55 makes the backend redirect to the frontend with a human-readable ?error= message on OAuth failure, instead of dumping raw JSON in the browser. open-social-web#32 is the matching frontend change — the login page now surfaces those errors inline (no flicker on first paint) and cleans the URL so refreshing doesn't re-trigger the message. And open-landing@26097f7 fixes a broken login button I'd been hearing about.

Event sharing, content sharing, and a community hierarchy

This is the biggest product-shaped change of the month: open-social#68 introduces two things.

First, a sharedContent model so events (and other content) can be shared from an individual to a community rather than living in just one place. Second, parent-child relationships between communities, which opens the door to umbrella communities, sub-groups, chapters, and other org structures people have been asking for. These are features being used now at https://atmosphere.community! If you run an ATProto local community, feel free to add your community to Open Social so that your community can share their content, too!

A lot of upcoming features will build on top of these two additions.

Landing page and docs updates

The marketing and docs site got some love too:

open-landing@a30a4e0 adds clearer information on what communities get out of the box, and open-landing@aea8795 adds documentation for the new sharedContent capabilities shipped in open-social#68.

Under the hood

A few things worth mentioning for contributors:

I've been running a lot of these changes through coding agents (Copilot SWE agent and Claude) with human review. You can see that pattern across most of the merged PRs above. It's been a great fit for well-scoped refactors and security fixes.

The DID work, the OAuth resolver work, and the new sharing model all push toward a cleaner separation between identity, community, and content, which should make future features easier to land!

If you're interested in a particular feature for your community used across apps, let me know or file a GitHub Issue!

What's next

I'm also working with a few more apps to integrate with Open Social's shared community architecture. If you're building an ATProto app and want your users to be able to share content into communities (or you want to use Open Social for community management), reach out! I'd love to chat about what integration looks like for your app.

On the infrastructure side, I'm looking into using Cirrus from Matt Kane for creating brand new communities and DIDs. Cirrus is a single-user ATProto PDS that runs on Cloudflare Workers, and it could be a really lightweight way to spin up new community identities without running a full PDS.

Thanks to everyone who reviewed, tested, and filed issues this month. 💜

— Brittany