Technology Snapshot 2024 Q3

I've gotten a few questions about what Smoke Signal looks like under the hood, and I'm happy to share.

I started Smoke Signal as a Rust project. I considered Golang and Python, and I quickly decided against using Typescript. Although most official projects and libraries are written in Go and TS, I've been enjoying writing Rust for personal projects and decided to stick with it.

Some of the key libraries that I'm using include Axum, Tokio, Chrono, Sqlx, and Atrium. Error handling is with thiserror and anyhow, although I've been looking at snafu.

The storage layer uses SQLite, which I will use until it tips over. I'm not using an ORM to generate queries; instead, I am using the FromRow trait Sqlx provides. For the time being, I'm writing all SQL queries by hand.

For the full-text search feature, I've opted for SQLite and its robust FTS5 extension. In the future, I plan to implement natural language features for filtering and scoping queries, such as "Give me events that I've RSVP'd to for this weekend ", which will further enhance the user experience.

The support site is a static site generated from Markdown files. I'm using Zola with the Adidoks theme.

The site is deployed using Docker containers, and Caddy manages static files and TLS.

The 'scale-up plan' for Smoke Signal is designed to leverage all that atprotocol has to offer. This includes storing all user data remotely in personal data servers and managing a stream of changes from the firehose. With this setup, the goal is to have independently operating instances and groups of instances distributed geographically. Considerations will need to be made for caching and homing users to regions, and geo-location DNS routing would work well for this purpose.