JohannaWeb

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.

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.