JohannaWeb's Project Falcon is a Discord-style desktop client built on top of the Bluesky AT Protocol. It has a front end written in Electron, done with TypeScript/React, and uses Java and Spring Boot 4 on the backend. The concept seems to be: what if Discord's UX wrapped a decentralized social graph instead of a proprietary one?
It's early but it looks like it works, and someone built it themselves, which is worth saying out loud with praise. Good job! Well done! May you and the project experience as much success as can be tolerated; high water raises all boats.
With that said...
What AT Protocol Actually Is
This is being pitched as a "BlueSky project," and that's fine, but we need to be precise here, because "Bluesky" and "AT Protocol" are not the same thing and are often discussed as if they are, just as if one says "web services" and thinks "REST," when REST is one approach to web services and not the only way web services can be implemented.
The AT Protocol is an open, decentralized protocol. Bluesky Social - the company, the app, the culture - is one application built on top of it. The protocol itself is indifferent to any particular community or political ends. Identity is portable via DIDs (Decentralized Identifiers). Feed algorithms are third-party and pluggable. Anyone can run a Personal Data Server. It's essentially uncapturable by design, which is a good thing; you don't want a platform to be controlled by a potentially untrustable actor.
But then there's the firehose.
The firehose is a real-time stream of all public activity on the network, openly accessible without authentication. This is a deliberate design choice - it's part of what makes the network uncapturable by any single entity. It also makes every public interaction on the network trivially observable by anyone, at scale, with no gatekeeping mechanism to even theoretically push back against. Centralized platforms at least gate their firehose behind ToS agreements, rate limits, and API revocation. AT Protocol removes that friction by design.
Uncapturable and unobservable are not the same thing. Worth knowing before you post. If you have a secret that you're trying to tell your specific group - that thing you want nobody else to know besides that select set of friends - the AT protocol is throwing that secret in front of anyone who watches the firehose. It could be me, it could be Russia, could be the NSA, could be anyone. It is not a secret, even if it pretends it is, and it's worse to play at security than just to be plainly insecure: sending a password in plaintext over HTTP is so obviously insecure that it barely needs to be said to avoid doing that. But here, there's a suggestion that something can be secure when it most specifically is not, by intent and design.
Why You Won't Find ByteCode.News There
The protocol's openness is a feature to its designers, and they're not wrong on their own terms. It's just not compatible with how this publication prefers to operate. We're architects and hackers; trust is earned, not claimed, and we're not going to be part of a system that burdens its users with assumptions about access.
With that said, Project Falcon looks like a fine piece of work. The protocol it's built on is what it is - open by design, observable by consequence, and worth understanding clearly before treating it as a refuge. And it's admirable that JohannaWeb built it on their own terms, for their own purposes, and that's entirely worth celebrating.