Lazurite

For about the past week, I've been hard at work on a BlueSky client that includes some experiments and quality of life features I've seen discussed across the platform. So far, I've implemented a lot of stuff and am continuing to iron out the kinks in the system. In some form or another I've added (mind you, mostly read-only, as I've been trying out everything with my main BlueSky account):

  • Feeds (all of them & pinned, defaulting to your top feed) with a cache in case you go offline

  • DMs (I've been talking to @thunderbot.bsky.social a lot as a test)

  • Profiles (with pinned posts!)

  • Post searching with saved searches

  • A repository browser inspired by pdsls. I even posted a video of it here.

  • Theming - for this I default to Oxocarbon (because I love it), and include some popular and well documented color themes like Catppuccin, Nord, and Rosé Pine.

I'm open to feedback and feature requests so by all means, ask away! I currently have 0 requests so whatever I get, I'll get to work on pretty quickly.

desertthunder.dev/lazurite
mobile bluesky app made with flutter
https://tangled.org/desertthunder.dev/lazurite

Once I make a couple of UI changes in the coming days and make sure I at least have some semblance of feature parity with the official app, I'll probably kick start the review process for app stores, which have historically been a thorn in my side.

Internals

Most of the way the app is structured follows established patterns and libraries. The app is structured with a four-layer separation of concerns:

  • Presentation: UI Widgets, State Management (Notifiers), User Input

    • Depends on Application & Domain

  • Application: Use Cases, Service Classes, Workflow Orchestration

    • Depends on Domain & Data

  • Domain

    • Business Entities, Core Business Rules

    • Independent (Pure Dart)

  • Data: Repositories, Data Sources (API/DB), DTOs

    • Depends on Domain (Interfaces)

The application layer uses Riverpod, a data binding framework that injects dependencies with a Ref object so that UI layer can use the data layer without creating unruly controllers/presenters.

Flutter App Architecture: The Application Layer
Service classes are the ideal place to store logic that depends on multiple data sources or repositories. Let's explore them by building a shopping cart feature.
https://codewithandrea.com/articles/flutter-app-architecture-application-layer/

One of the things I appreciate about mobile development is the adherence to design patterns in official documentation and guides & essays. Though small, the Flutter community seems really enthusiastic and kind, and has been incredibly helpful as I work through some of the roadblocks I faced back when I first attempted to build mobile applications with it last year.

Workflows

I wrote in a previous post that I'd like to talk about some of my AI related workflows. For this project in particular I'd been doing what I usually do, which is draft a thorough roadmap.txt file, discuss an implementation plan with my assistant and have it work on the task or feature at hand. When its done, I write test cases and QA, and iterate on my own, then have it complete the tests. Usually this is with Claude Code but this week (literally until this morning), I'd been using Opus with Google's Antigravity IDE. Now I use a combination of Gemini 3 Pro to plan and Gemini 3 Flash to implement. Shockingly, Gemini is not very good at writing Dart code.

In general, I usually end up rewriting a lot of this code by hand because I have some style choices I like to adhere to and because combing through generated code helps me keep my mental model of a system intact.

Looking Ahead

In the near term, my plan is to have Lazurite at least in TestFlight for iOS and an internal test for the play store. It would be cool if I could get the app in F-Droid too but like the other two channels, what that really means is that I'll have to spend some time researching.

Into the New Year, I'd been working on Malfestio and a few smaller web projects. I've got a plan for hosting Malfestio with a few different services and will deploy all the apps. The one common thread between all of them (besides me having to write more TypeScript than I want to) is that they employ Dexie for local-first storage. I'd built Volkara last summer with PGLite to mirror the full data model on the server but many of these have way simpler models. Plus Malfestio relies pretty heavily on the AT Protocol and uses PDServers as stores with private data in the application's Postgres database. Dexie is there to make indexeddb easier to work with and make sure there's no data loss. Deploying the desktop builds for the other projects will take some figuring out. I'm thinking a cloudflare worker that runs the build and pushes to some registry but the SPAs themselves will at least live on Cloudflare pages.

desertthunder.dev/malfestio
learn and share notes on atproto (wip) 🦉
https://tangled.org/desertthunder.dev/malfestio

Before getting obsessed with building with the AT Protocol, my focus was two major projects: the Baseball Stats API, & Beacon (Hindley-Milner Type Checker & LSP for Python). I have a VPS provisioned for the baseball API and have been putting it off just due to the sheer size of the database I'll have to build. There is a TON of data.

Beacon on the other hand, is a really really complex and cognitively demanding project. I mentioned in a rant very early this morning that I've been dealing with the loss of a family member and I often am unable to handle the demands of the project. I'm also not sleeping a ton because of it. In time I think I'll return to the project and get it done because I think it'll be really great when I realize my vision. For now though, a little bit of UI and straightforward application development is the best I've got.

Thanks for reading.