Welcome to Brine 2

This is Brine 2, my new blog that I'll be using from now on. It looks similar to the previous Brine blog, but it is much different internally.

Brine 2 will operate in tandem with my Leaflet publication, Kuruma. In short, more personal thoughts and ramblings will be on here, while Kuruma will be aimed for things meant for a more public audience, such as guides.

A modern web browser will unfortunately be required for all of the hyperlinks on this page.

About Brine 2

Brine 2 achieves a long standing goal of mine: to bring the power of the AT Protocol to older computers. ATProto has been one of my interests for a while, but it being new tech means it doesn't get along with older computers. Virtual machines can help, but what if you wanted to access ATProto data natively from your retro PC? Pretty much all AppViews require HTTPS and the latest web browsers, except for one: Blahg.

Blahg was created by the team behind Smoke Signal to run their blog. It's a self-hostable Rust-based AppView that gets its data from your PDS, and importantly stores it server-side so it can be served over unencrypted HTTP. Blahg's frontend consists of HTML templates that can be easily customized to become the final piece in the puzzle to make a legacy PC friendly AppView.

Brine 2 runs on a modified fork of Blahg called BlahgLegacy, featuring a new legacy friendly UI and a few new features, such as subtitles, and like any good blog, tags.

It's a big step up from Brine 1, as there's now native Markdown support and I don't have to rawdog HTML anymore which makes it much easier for me while still allowing mostly everything I need.

Despite all this, BlahgLegacy is still not an ideal solution, namely, the lack of categorization by date on the main page, all the hacks I had to do to add those new features (I don't actually know Rust lol) and the fact the original Blahg appears to have been predominantly generated by AI (I had to fix several easily fixable bugs, for starters). In the future, I might use a different AppView that supports its lexicon, which would eliminate these issues while keeping compatibility, but for now, BlahgLegacy will suffice.

Why not just use Leaflet for everything?

Leaflet is a publication site, not a blog, and I believe that publication sites like Leaflet are not really meant for blogs. It's not helped by the lack of blog-esque features like tags. You can certainly use publication sites as blogs, but I believe in separation of more personal writings from those directed at people.

All of that is however nitpicking. In truth, there is one crucial issue with Leaflet that makes it ineligible to replace my blog: it doesn't work with older web browsers.

Timeline of BlahgLegacy

9th

I (re-?)discovered Blahg after seeing someone star it in the Tangled timeline. My first problem was being unable to compile it from source, as I had excluded the PostgreSQL backend. I fixed this by adding a missing #[cfg(feature = "postgres")] line. The next issue was being unable to set the author variable which is required to make Blahg work. Eventually I found out this was because the readme was wrong; there is no BLAHG_ prefix. With that being corrected it now ran!

I forked the Blahg repo and fixed those two bugs, and then added the ability to configure the Jetstream instance to use, as well as adding support for description metadata. The last thing I did was give the UI a makeover that made it play nicer with older browsers. This UI is based on Brine but 'unbranded', featuring different colors and some minor changes. Of note is the unvisited URL color, #FF73B3, which was formerly the default accent color used in the UI for self-hosted PDSes.

10th

The first thing I did was make the description metadata optional, and then found and fixed a bug in blahg-import that caused the URL to have the rkey twice. This was actually fixed for the Jetstream consumer by the original developer, but evidently they didn't catch it for blahg-import. The majority of the day was spent adding tags to Blahg. Oddly, listing blog posts by tag wasn't too hard, but showing the tags on the post page took me way longer to figure out.

11th

The only thing I did was adding support for tag search and display with the PostgreSQL backend, which I don't use.

12th

After touching up some of the HTML templates I added support for subtitles in blog posts. After that I wrote some code to be able to set the listen address from an environment variable. Finally I changed the way dates are imported in the database: blahg-import now stores the creation date declared by the post rather than when it was imported, and updatedAt is now taken from the post in both the Jetstream consumer and blahg-import.

13th

Originally I wanted to officially rebrand the fork Blahg as BlahgLegacy, but I put this off. I ended up only published a bug fix for importing posts with tags, as I hadn't tested that yet.

14th

I added support for Jetstream compression after noticing the consumer was using a lot of bandwidth: something like 300 KB per second. That adds up quick and is over 700GB per month! While I was there I also discovered that setting collections wasn't working properly. This was actually due to a bug in the atproto-jetstream crate; I updated it to the latest version and it now works properly.

15th

This was the big day, it is now officially BlahgLegacy! I also hooked up the BLAHG_HTTP_TEMPLATES_PATH variable after noticing it wasn't doing anything.