Hello everyone! It's been roughly 24 hours at time of writing since Colibri was released. In those 24 hours, Colibri grew from a small side project and proof of concept to something bigger. Within those first 24 hours, we've had over 8k people visit our website. We've made #4 on HackerNews, have received very positive feedback on all fronts, and have scrambled to deal with the implications of this.

So let's take a look at what we're currently doing, what we're planning on doing within the next week, and what we're trying to focus on long term. This post will explain the immediate To-Do's, the features we're hoping to cram into the old architecture, and the architecture rework that should allow Colibri to grow more reliably and easily.

The Current State of Things

As mentioned previously, Colibri, at least until around 24 hours ago, was nothing more than a prototype. There exist zero test cases for any of the code, neither for the app view nor for the site and/or app, and the only CI we've got is a linter that screams at you if your PR has improperly formatted code in it. That's fine for a private GitHub repository where you're just pushing to main. But it definitely won't do for a young but growing community project.

The actual code isn't much better off. The main repository with the website and app was hastily thrown together. It contains duplicate code, race conditions, weird and counter-intuitive ways of fetching data that comes from various places, and it performs horribly. The app's code is also heavily tied to the Astro app. It's honestly an achievement the app managed to survive this many people slamming it with requests.

The app view faces the same problems, as the initial implementation was intended to serve as a prototype - it's heavily vibe-coded, contains a lot of spaghetti-code, and is counter-intuitive to work with in many ways. At least it's performant. Thanks, Rust.

Up until around 3 hours ago (at time of writing), we didn't even have GitHub community health files and issue templates. Luckily, and stepped in and helped us in getting those set up. Thanks!

We've also just applied for an Open Collective account to get the hosting situation under control. All infrastructure is currently running via 's server, which he's paying for out-of-pocket. It'd be nice to see that changed.

The Immediate To-Do's

While Colibri's rework is already on the horizon, there are still some things we'd like to cram into the current code base so the app is a little more usable while you are waiting for the rework. These include:

  • New Facets

    • An @time mention to send timestamps that everyone can see in their local timezone

    • Multi-line (highlighted) code facets and first-party list support

  • Support for Bluesky's new "bot labels", so people can start with making bots that work with Colibri

  • A new channel type for "links", so Owners can directly link to other sites from within the app. Think 'a channel that links to an external page when you click on it'. Thanks for championing this!

We'd also like to get the Open Collective up and running, just so it's there in case people want to support our work.

We've also been approached by and the roomy.space team and will be jumping on a call with them to talk about the similarities and differences of our two projects. You'll be able to watch that live on stream.place when it happens.

The Long-Term Plans

Now then, let's talk about the interesting things. In our alpha announcement post, we've already talked about the new infrastructure layout briefly. Now, we're expanding on that. Here's the earlier diagram again, for your convenience:

The new architecture consists of 7 pieces:

  • The app view

  • A tap instance

  • A standalone SolidJS app

  • The website which serves the app for the same experience as before

  • A Tauri wrapper, used to ship the app to desktop and mobile devices

  • A Redis database used for caching and short-term storage

  • A PostgreSQL database used for storing records the tap instance collects, alongside session information, and data that cannot or should not be stored in the AT protocol

The New App View

The old app view was written in Rust, and that won't be changed for the new one. It handled the initial load of the launch just fine, so we'll keep sticking with rocket.rs for now. It provides good handling for both HTTP requests and WebSocket connections, which is what we're using to make the real-time aspects work.

While the current OAuth system is implemented in the Astro site, the new app view will also take care of that, allowing us to implement more features via WebSockets that were previously impossible due to the split nature of the system.

The app view will also continue handling Colibri-specific features that cannot be stored on ATproto, like invite codes for communities, which need to be kept private for obvious reasons, at least until permissioned spaces are implemented. We will reconsider where to store them then.

Additionally, the app view will take over in handling the short-term data we store, like embeds for links. For that, it is connected to a Redis database, that can be used for caching tasks in the future.

One thing this new app view does not handle is backfill functionality and record indexing from the ATmosphere. For that, we will use a neat little piece of tech called...

Tap

Tap is an all-on-one tool made for repository synchronization by the Bluesky team. It was made to make the hard parts of working with ATproto events - backfilling older records, recovering un-synchronized repositories, and filtering output - easier to implement and work with. We'll be relying on Tap to handle this capability that was previously built into the app view itself.

Tap will subscribe to any repositories containing messages, reactions, or any other data related to Colibri, and make sure this data is 100% available and accurate.

Any data it collects is saved in a shared Postgres database that both the Tap and the app view have access to. The app view will also subscribe to the Tap, consuming real-time events for records that are created, almost like it is currently doing from the Jetstream. It then forwards these events to the clients that actually require them, so your app does not get spammed with events for communities you're not a part of. Speaking of the app...

The App

While we won't be rewriting the entire app from scratch, the rapid iteration over the past month has made the current structure less and less fun to work with. There's lots of duplicate code, data comes from a lot of different places, it's heavily tied to the website because of the OAuth functionality, and some places are desperately missing some code splitting. So we'll be making a big refactor to improve performance and make future maintenance easier.

The new app will still be built in SolidJS, and it will look mostly the same, minus the few changes we have to make for the new structure. It will also still live in the same repository, but it will be in it's own sub-directory, decoupled from...

The Website

The website probably won't change at all in terms of design. It will still look the same and provide the same functionality, and it will still serve the app for users who want to use their browser to chat. The only difference here will be that OAuth is now handled by the app view. Oh, and there will be a new "download" page for...

The Tauri Wrapper

It wouldn't be a chat app without an actual app, would it?

Tauri is a framework for building tiny, fast binaries for all major desktop and mobile platforms. We'll be using it to make Colibri an actual, installable app. The Tauri wrapper will also be living in the main monorepo, so all code related to the app can easily be tested in one go.

The To-Do's for the new Structure

We've got quite a bit of work ahead of us! Here's the two main things that we consider necessary for the new structure to work:

  • We need a test suite for the app itself and the app view that we can run on PRs to make sure nothing breaks

  • We need better tooling for development, like deployment previews

Besides the must-have's, there's some new features we would like to implement once the new architecture is ready.

New Architecture, New Features

This is where it gets spicy. We are looking to implement:

  • Message Indicators and Pings for channels, similar to Discord

  • Notifications, on web and desktop

  • A new record structure to rely less on your Bluesky profile (while still allowing you to sync it to the app)

  • Even better moderation tooling related to voice chats

  • The ability to designate users as moderators for a community

  • A command palette for easy navigation

  • Better context menus wherever possible

  • Setting maximum uses for invite links

  • Integration with other (ATproto) services (we'll be talking about this on the call with the roomy.space people!)

  • Better Bot-Tooling (maybe even some libraries for authors?)

  • A new forum channel type

  • The ability to convert channels from one channel type to the other, seamlessly

  • Being able to remove/re-add embeds from/to messages you've sent

The only thing missing from here are private communities, and you are probably wondering why we have not talked about that yet. Truth be told, we're not sure when exactly the AT protocol will support such data. We're hoping it'll be around the end of Summer 2026, like the ATproto team said in their Spring 2026 roadmap post.

That's it for now though. If you want to get involved in shaping the new architecture, join us on the Colibri Social Community! We'd be glad to have you. Until next time.