Show HN: Falcon – Chat-first communities built on Bluesky AT Protocol | Hacker News Reader

Show HN: Falcon – Chat-first communities built on Bluesky AT Protocol

5 pointsJohannaWeb4 comments

I’m building a chat-first community app that uses Bluesky’s AT Protocol for identity.

Current architecture: - Electron client - Spring Boot backend (monolith) - REST for servers/channels - Planning WebSocket-based messaging

As a solo builder, I’m trying to balance simplicity with future scalability.

At what point would you introduce: - a separate WebSocket gateway - pub/sub (Redis, etc.) - or keep everything in one Spring app until it breaks?

Curious how others approached real-time chat systems early on.

Project for context: https://github.com/JohannaWeb/ProjectFalcon

View on HN

Re: when to add a WebSocket gateway vs keeping it in the monolith —

I've built multi-channel chat infrastructure and the honest answer is: keep the monolith until you have a specific scaling bottleneck, not a theoretical one.

One pattern that helped was normalizing all channel-specific message formats into a single internal message type early. Each channel adapter handles its own quirks (some platforms give you 3 seconds to respond, others 20, some need deferred responses) but they all produce the same normalized message that the core processing pipeline consumes. This decoupling is what made it possible to split later without rewriting business logic.

On Redis pub/sub specifically: for a solo dev, skip it until you actually have multiple server instances that need to share state. A single process with WebSocket sessions in memory is fine for early users. The complexity cost of pub/sub isn't worth it until you need horizontal scaling or have a separate worker process pushing messages.

What's your current message volume like? That usually determines timing better than architecture diagrams.

This is super helpful — thank you. And I agree with the “pressure before architecture” principle.

Right now Falcon is still very early — message volume is basically zero outside of local testing. The service split isn’t driven by traffic yet, it’s more about separating identity/trust from messaging so I don’t entangle community membership logic with transport.

The internal normalization point you mentioned is something I’m trying to do early: the goal is a single internal message/event model that adapters (WebSocket, future federation, etc.) translate into, so the core pipeline stays stable if/when the runtime topology changes.

On Redis/pub-sub: totally fair. I’m not running multi-instance yet. JetStream is more experimental at this stage — mostly exploring how identity-aware events propagate, not solving scale today.

You know having a license for your project is a good thing, do you? I strongly encourage you to use GPLv3. Anyways, were you so lazy you generated the README.md with AI, or did you put actual effort in it? And why the AT protocol?

I’m already using GPLv3 — I want Falcon to stay open and for improvements to remain in the commons rather than becoming closed forks.

The README wasn’t AI-generated. I wrote it and iterated on it a lot — though I’m sure it still reads rough. The goal right now is clarity over polish.

Re: AT Protocol — the main reason is identity portability.

Most dev communities today are anchored to a platform (Discord/Slack), not to an identity layer. If a server disappears, the community graph fragments. AT gives:

DID-based identity

portable handles

a protocol-native social graph

I’m exploring whether that can support communities that aren’t tied to a single host.

Still very early — a lot of this is experimental.

Reply on news.ycombinator.com