Entire post here: https://github.com/torlando-tech/columba/blob/main/september-2026-update.md, split into multiple posts here due to character limits

An update on Columba Development

Hey everyone. It's been a while since I wrote to the community, and given some of the recent drama, I thought it would be good to communicate with you all.

Feels weird to need to point this out, but this post is entirely my own writing, no AI usage at all.

The near future for Columba

I have tagged a stable v2.2.5 release, just haven't actually hit the publish button yet. I don't think there's anything glaring in v2.2.5-beta, which is great, so as soon as I have time to do one final manual regression test on the new stuff added since v2.0.9, I'll either publish that release, or postpone til a v2.3.x. I tend to work a little ahead of even the pre-release, and espcially as I add new features, I tend to let them pile up a bit before releasing a new minor version. This also means that sometimes I notice bugs that are present in the current pre-release after I've already merged in new features, and have to decide between backporting the fix to something like a release/v2.2.x branch (branched from the tag for that release), or just barrel forwards. I've done both and frankly the latter is a lot less maintenance on my part, but it also means that users who want to stay on stable releases will have to wait longer on average in between updates.

I'll save listing the new features in v2.3.0 for an actual release announcement, but it's a mix of support for newly released RNS functionality, and emabarrasingly old feature requests from the community that I've finally had time to put attention towards (along with bug fixes and stability improvements). I'm still working through that backlog, but at least ther are roughly a dozen fewer open issues on github, and roughly half the open PRs. I'm also still working through getting more added to it, so it'll be a little bit still before it's available for pre-release.

There really aren't too many more features I really have planned for Columba; stability and efficiency are higher priorities for me. I'd like to get it published on the Google Play store, but I expect Google to have some issues with some of the features, and might have to remove some of them for the Google version if they flag anything. I expect the APK sharing feature, or checking GitHub for updates, to be flagged, since I'm pretty sure they only want you updating an app through their store. Anyway, while I've started that process, it's pretty tedious and boring, so I haven't made a ton of progress on it.

Work on iOS continues

While I do have a mostly functional iOS version of Columba that has been on a private TestFlight group for some time, the biggest gap is background operation. In its current state, Columba-iOS uses RNS via Beeware, but as expected when the app is backgrounded, it is soon (immediately? haven't measured) suspended. This means that if Columba is not open on your screen, and someone sends a message, you won't get it; you aren't connected to a reticulum network, you won't receive the packets, you won't send a delivery proof, and the sender will (hopefully, depending on their client) send it as propagation instead. This is less of an issue for messages that reach your phone via a BLE connection, for reasons I'll get into below. Depending on how often and how quickly you switch apps into and out of Columba, this suspension can get you blocked by the default fast flapping settings on a Backbone listener relatively easily, so it's really not ideal to ship it in this state.

There are a few ways Apple provides apps time to work in the background, but none of them perfectly fit Reticulum's use case. Here are the ones that I've incorporated so far:

1. CBCentralManager With the UIBackgroundMode bluetooth-central. This (is supposed to, at least) allow packets in from RNode or other reticulum devices using ble-reticulum (when your phone is the central side and the other is the peripheral side) to wake the app in the background and process it. I've had message notifications work this way while backgrounded but it hasn't been consistent.
2. CBPeripheralManager and UIBackgroundMode bluetooth-peripheral. This is for the other side of the ble-reticulum connection (role is negotiated by MAC sorting).
3. BGProcessingTask and BGAppRefreshTask to periodically sync with your selected propagation node. But, from reading a bunch of posts of people trying to do various things with this, iOS doesn't guarantee a strict schedule for when these run, it may run at different times and intervals depending on whether your phone is plugged in or has been unlocked recently, and the longer you go (days, weeks) without opening the app, the less frequently iOS will schedule the task to run.

There are a few others that I mean to explore, such as location and voip (perhaps sharing your location to a peer in LXMF could keep it running in the background, or something could stay listening for incoming LXST link requests) but it definitely feels like workarounds and swimming upstream.

What this boils down to is that, if the above is all true (needs more time testing to be confident), receiving messages over the BLE radio (whether from a paired RNode or a ble-reticulum peer) work fine while backgrounded, but receiving over the wifi or cellular radios do not. This puts it in a similar position as meshtastic, where a companion device maintains connection to the network, and wakes the app via bluetooth with a drainable message queue.

But, this isn't really ideal, since at this stage (since there aren't any big RNode networks in the U.S., where iOS is more common) the most likely users will be relying on TCP connections to public backbones for communicating. Sure, you could set up a raspi in transport mode with reticulum-ble and a TCP connection at home, but when you leave the house you lose TCP connectivity (while backgrounded, by way of the transport node in the raspi). You could run microReticulum_firmware on an ESP32 based device, pair it to your phone like an RNode, configure it with a TCP connection, but then when you leave the home wifi it again loses TCP connection. You could even use your iPhone's hotspot to provide wifi to said ESP32 (or even raspi) and get around it that way, but this starts to be a lot of hoops to jump through (and huge battery drain, I've been told).

What about VPN apps?

VPN apps on iOS do indeed run indefinitely in the background, using a Network Extension. When an app comes bundled with one of these, you'll have to accept it in the system settings as a VPN, and the VPN badge will show in your system tray or whatever iOS calls it. The NE itself is a separate process from the main app, and is the only part that runs indefinitely in the background. This is what mostly closely resembles the architecture that android columba uses - there, reticulum runs in a separate foreground service and the UI app communicates via AIDL.

I'm still pretty early in experimenting with this and have a lot to learn here. I've also been led astray by LLMs several times with this, leading to wasting a huge amount of time (and tokens) working around constraints that might not exist. Part of the problem here is that not everything is well documented (see the background processing task I mentioned earlier). For instance, a model told me that RNS could not run in the NE due to the NE's tight memory budget, but it kept changing what that budget actually is (which led me down an entire misadventure with trying to port reticulum to swift, more on that later). It also told me that bluetooth was not a supported background mode in the NE (which is technically true) when it tried to declare it as a UIBackgroundMode (which is only for the UI app I guess and not the network extension). This led me down many wrong turns trying to figure out how to bridge BLE events in and out of the NE, originated from the app's BLE manager, if the reticulum runtime was going to be only in the NE. I also spent a lot of (brain only) time trying to design some sort of hybrid shared instance architecture, where reticulum would run both in the NE and the app, the NE would handle TCP, the app would handle BLE... but the more I thought about this, the more problems I uncovered and luckily didn't waste too much keyboard time on this.

This entire approach does carry some risk of Apple rejection, but I'm hoping that the existence of orbot for tor is a good sign that they're open to creative uses of the NE for uncommon networking stacks. One of my biggest gripes is that you can't even build and install an NE yourself without a paid developer account, but I had already purchased one anyway to avoid having my legal name on the app store. Ugh! This would lock most people out of being able to sideload columba themselves, which I'm really not a fan of either.

Anyway, the experiment I'm currently working on is whether RNS itself really can be the sole reticulum instance, running in the NE only, communicating with the UI app over IPC. I'd previously gotten microReticulum to work (with BLE!) in the NE, so I'm hopeful that this will eventually work. If I do run into memory limits (and the LLM didn't just hallucinate this) running RNS, I will try reticulum-go, and then microReticulum again (but I'd rather use something that is already feature complete so I don't have to build any part of the actual reticulum stack myself, more on that later). If after all this, Apple rejects the use, I will be super bummed and looking for more ideas.

Why not just use APNs?

For the uninitiated, the Apple Push Notification service is how most apps get push notifications. It goes through Apple's servers, and would require something on infrastructure that I would operate to tell Apple that YOU need to get a push notification that a message is waiting for you on the propagation network. This to me is antithetical to the ideals of reticulum. I haven't looked into it in detail, but my impression after some extremely cursory reading is this is the approach jrl's RFed took; extend propagation nodes with some process that tells Apple when a given destination hash has a message it needs to pull down.

This is a bit of an interesting case for Columba, because if Columba-iOS can receive background messages from BLE/RNode anyway, then it's only missing out on messages from TCP, which in most cases is going to mean the messages came from someone you needed the internet to communicate with anyway, and so it's reasonable to say, well, if I need the internet to get a message, then APNs is probably available too. I know folks (myself included) use TCP to connect to a LAN-local transport node, but hopefully you understand the problem I'm talking about here.

If all else fails, I may one day turn to the community to see if there's acceptance/desire/sentiment around RFed, but for now I am trying to find an alternate way that doesn't rely on any cloud infrastructure at all.

On my own AI usage

It's no secret that Columba (and ble-reticulum before it) was, from the beginning, developed with AI coding tools (almost exclusively Claude Code). I left Claude as a contributor on columba's gh repo quite intentionally; I didn't want to hide the fact that I'd used it, but also knew better than to proclaim loudly that I had used it. In those early days, it was Sonnet 4, which in retrospect is probably why 1. I was so in the weeds with it and 2. learned a ton about BLE in the process, because it really needed a ton of steering. I was tempted many times (and succumbed often) to just let it run on autopilot for a long time, often while I turned my focus to my day job. This never really worked very well; I wasted tons of time and tokens disengaging with the process, only to need to unwind what it did and steer it properly towards something that was more likely to work. I had to push back a lot, steer often, correct frequently. And, I had to test everything meticulously, manually. I had to translate BLE GATT concepts in my mind to the RESTful API world I was coming from, and really come up with most of the what and why on my own, only really leaving the how (the syntax) to the LLM.

As newer and bigger models came out, and I gained more experience using Claude Code in my day job (which, being a Java + React shop, is really much more on-distribution for the LLMs than reticulum or audio pipelines or lora parameters or firmware or or or), I was tempted to take on bigger and bigger features in Columba. Opus 4.5 eventually was released and became the main model I used for everything, and a ton of new features shipped for Columba during that time. I was highly engaged with the community matrix channel, I was getting lots of bug reports and feature requests, people were expressing gratitude for my work, I even received a few donations.

The psychology of an AI subscription

In the early days, probably June of 2025 or so, my employer heavily encouraged that I get a personal subscription to claude code, and use it for work, and it'd be reimbursed. The recommendation was (rightfully, given the usage to cost ratio), to get the $200 plan. There was no restriction on only using it for work, and since it was a personal plan, they had no way of tracking what else I did with it anyway.

This was a new and shiny thing; it had only been a few months since claude code's release, and at work we'd previous tried github copilot and cursor. But at the time, claude code was an entirely new capability level. From what I've read since, it was the first harness to have its model trained on its tool calls and usage, so they had a leg up on the others. The code it wrote wasn't always the prettiest, sometimes it needed things to be fixed manually afterwards, but it generally got the low-resolution shape of whatever you asked for right. And it was way faster than me typing myself, even on mundane stuff like writing out a data model.

The broader SDLC hadn't really caught up with this at my job, so I was finishing my work in much less time than before, and after having been in this career for just barely 10 years at the time, I'd already learned the lesson the hard way that busting my ass and working really hard made absolutely zero difference come annual review time, so I just let my mind wander to other things. I started trying crazy ideas in side projects in areas I had no experience with. Sonnet 4 spectacularly failed at doing some custom graphics rendering pipeline for a game mod, and a few other related things that will never see the light of day.

Anyway, the subscription. I had all this usage that wasn't getting used. All these tokens that were being paid for regardless of whether I used them, so I had to find ways to use them. Eventually the free ride at work ended - we got a proper business plan, and my personal plan was no longer covered. I can't remember the exact timing, but I must have already started columba, because I made the insane decision to keep paying the $200 for claude, and I can't imagine having done that unless it was to keep working on columba at the pace I'd grown used to. AI coding was being presented as an important skill for my career, after all, and broadening my area of experience (from full stack web into mobile) had been really fun and engaging on its own.

As time passed, I didn't always have enough columba-only work to "really get my money's worth" out of the claude subscription. So long as I was using more than half the weekly usage, it was still a better deal than the $100 plan, and I already knew the $20 plan was really not suited for claude code use on a project all the time like I was using it. Some nights I'd have five or even six separate terminal windows open working in separate worktrees on bug fixes or features for columba. This was basically what it took to "get my money's worth" and use all the usage. And of course, I couldn't meaningfully engage with that many sessions at once, but the results were working, so I ignored any apprehension I had about letting go of the details so much and just kept pressing forward. When all the plates were spinning, instead of engaging with the details I'd already delegated away to the machine, I'd let my mind wander to whatever I wanted to build next.

There were a lot of things I started and never released during these few months. I saw the t-deck and thought, wouldn't it be cool if there was a reticulum firmware for that? Claude was even worse at writing firmware, but with enough persistence it kinda worked! That was exciting. I did at least release Pyxis, with plenty of "this barely works" disclaimers in the readme, but if I was out of my element with android development, I was on another planet with firmware development (speaking of my own background and experience). More on Pyxis later.

Maps! I'd added maps and location sharing and offline map storage to columba, but had to rely on downloading over http to get the maps. That's no fun. There should be a way to get them over reticulum! I spent a silly amount of tokens building a map sharing protocol and server and management web ui (and even an integration path in columba) that I never released because I never found the time to unsloppify it and sculpt the hunk of software it had generated into a thoughtful, intentional software stack that I felt comfortable releasing.

RRC! (Okay this on actually did come out, in Eridanus). What a neat idea, what a great read in the specification. A mobile client shouldn't be too hard, right? And I can make it a local client only for a shared reticulum instance, should be a good candidate for a kotlin-only client, right? (no, as it turns out, the shared instance parts of transport are pretty complicated). But at least I released this one. (And no, I won't be adding RRC support to Columba. Columba is already bigger than I ever planned on, and I wouldn't have made Eridanus if I'd been open to adding RRC to Columba)

Group voice! My friends and I still make time to meet online and play computer games occasionally, and we use discord for group voice and occasional video streaming. Discord has long grown into an enshittified social media platform far beyond the basic group voice we really needed it for, but intertia is strong in this group, so we're still on it. So I spent tokens and time building and testing a cross platform desktop app for group voice over reticulum, and a server daemon to go along with it. It worked, but I hadn't really read through the details of the protocol, and wasn't comfortable releasing it without reading (and most likely heavily tweaking) that protocol documentation.

All of this because I needed to "get my money's worth." Layer on top Boris Cherney saying stuff like, "I run a thousand agents overnight" or "use opus for everything," and all of this talk towards using more and more tokens to solve problems with using tokens (adversarial reviews! loop engineering! mixture of agents! use a smarter model! spend moar!) in retrospect just feels so silly to have gotten swept up in.

The biggest time sink of all

Okay, what about battery life in columba? I was consistently getting two flavors of comments from the community regarding the battery consumption of columba.

1. Wow it's so much better on battery than Sideband! (which I don't think is universally true anymore, btw)
2. Wow this uses 10x more battery than anything else on my phone!

Naively, I hypothesized part of the reason Columba had better battery life than Sideband was that it only used python for reticulum itself, where Sideband uses python for everything (the UI too via kivy). Kivy is great for one UI that runs everywhere, but the whole reason I'd started columba (aside from wanting to bring ble/bitchat to reticulum) was to make a more intuitive, familiar interface for android users. All this jetpack compose stuff was "native android" (still don't know what that actualy means) so I thought, okay, let's see if AI and I can make a reticulum implemention in kotlin, targeting android. We'll use JVM for as much as we can to facilitate automated testing, set up a test harness that connects a running RNS instance and reticulum-kt and treats them both like a black box, testing outside from every scenario that I can think of, adding more (TDD style) as I find bugs and learn more about reticulum itself in the process. While we're at it, I can address a few pain points I've had in columba with RNS (move reticulum configuration to a database, make interfaces hot-swappable). Finally I won't have to maintain this giant godclass that claude kept vomiting into. Finally I won't have to bridge out to kotlin from python every time I want to talk to the BLE radio. Surely this will be more efficient. And, on my phone, it was!

For something like two or three months, I worked on reticulum-kt and a reticulum-conformance (language agnostic pytest suite) as one of the multiple plates I was spinning, while also making forward progress on columba itself, and slowly refactoring that terrible godclass into smaller pieces. I even made (and never released) a standalone app that runs reticulum-kt in shared instance mode, with quite a few more interface types than what columba has, to use as testing. I did the same thing for RNS itself (actually released as reticulum-android on my github) and would use the two of them, one day at a time, to test battery consumption. And the kotlin battery life was way better, on my phone.

I was approaching a bit of a deadline in my personal life, after which I knew I would have literally zero time for about 10 days to touch columba at all, and after that signficantly less time for months. I knew I was close on reticulum-kt. I had tested everything I knew to test. I had integrated it into columba. I'd been using it as my daily driver for some amount of time. I shipped the pre-release columba v1.0.0 with kotlin as the only option, along with an announcement on github about the breaking change nature of it (not directly tied to the reticulum-kt migration, but done at the same time).

After said 10 days passed, I resumed work as usual, albeit at a much slower pace (personal life was and continues to take more time than it used to). It wasn't long before Mark rightfully removed Columba from the manual, for using an AI generated, unverified reticulum implementation. This was pretty crushing for me, and took me well over a week to recover from the anxiety. The worst part is, I'd sent him a message from my kotlin client a few weeks prior, and never got a response from him. It wasn't until I read one of his forum posts that I realized he had never received the message. Turns out the LLM had never wired up the LXStamper in columba, and Mark's client was requiring a stamp, so he never got that message. I should have tested this. I should have noticed the missing dependency injection. It was incredibly embarassing, and I really felt like I had let the community (most of all, Mark) down. After a lot of "soul searching" as they say, I decided to adopt the dual-backend architecture that columba still ships with today.

I'd also gotten several really detailed reports about battery life in columba from users who had tried all three of columba rns, columba kt, and sideband. For the people who sent me reports, columba kt was only marginally better, if not basically identical, to columba python, in terms of which had consumed more battery. So the kotlin implentation was 1. not univerally improving battery life like I'd hoped, 2. was causing me a great deal of embarassment, anxiety, etc., and 3. still taking a lot of my time as I tried to find and close gaps between it and RNS. And of course, despite having gone into this whole ordeal thinking that Reticulum was more or less a stationary target I'd be aiming for with this port, Mark pushed RNS 1.1 and 1.2 (maybe even 1.3, I can't remember) in between the time I'd started reticulum-kt and when I released Columba v1.0, adding features and changing details in Transport that I knew were going to be time consuming for me to fully understand and reproduce in reticulum-kt.

Then, there was reticulum-swift. Another vector of assumptions that led me down the path of porting reticulum not once but twice was the incorrect assumption (due to trusting the LLM when I shouldn't have) that there was no way to run RNS inside an iOS app. I thought, well, I'm going to have to do this for iOS anyway, which people keep asking for, so I'll make sure to use a language-agnostic test suite that covers both ports at once as I go along. I'll take the basic design decisions I've made on reticulum-kt and apply them to reticulum-swift. This of course turned out to not be necessary, and still had all the same problems with background operation that I mentioned earlier in this post. Ever since I discovered Beeware (thank you, newer LLM, I guess), I have been using RNS instead (aside from the microReticulum NE experiment I mentioned earlier).

Brandolini’s

In the days following Mark's Brandolini’s Reference post, I've received a few questions from folks about the use of AI in reticulum-kt (no one has asked about reticulum-swift, fwiw). The mode of operation I was in while developing reticulum-kt was a mix between the two modes he describes. It wasn't generated with a loop (no "loop engineering" or probably even /goal usage; I have rarely used /goal and it might not have come out until well after I'd started reticulum-kt, I can't remember), I had specific pain points I wanted to address (I mentioned the db and hot swap earlier, but as I'm writing this I am remembering that I also wanted to be sure as much as possible was event/callback driven instead of polling (though this was more present in columba itself than reticulum), and I wanted to have knobs to turn in reticulum itself to run some things less often to preserve battery life, even having the ability to select a battery profile from the app side). But, there were plenty of times I had it generate a /plan (that often took some iterating on) before having it implement said plan, and I'd just test it from the outside without meaningfully engaging with the details of the code. And of course, since the reference implementation is the spec, I had it cloned in a neighoring directory and told the LLM to reference it often. I'm not proud of this, but that's how it went down. So, it's not an "either or" in terms of "substitute" vs. "operator" but more of a spectrum that shifted depending on the complexity of the task, or how interesting the particular element was to me. I put a lot more effort (but not enough, obviously) into testing.

So where does that leave reticulum-kt and reticulum-swift? Well, reticulum-swift seems to really have no purpose at all, so I will likely archive it with a link to this post explaining why. But, reticulum-kt ships as an experimental build option in columba, and somewhere between 10 and 20% of the downloads (I eyeballed numbers here but didn't actually calculate it) are the -kt version. The handful of vocal users of reticulum-kt seem to be disproportionately passionate about the license issue, which as I've mentioned before, I really am not interested in. I like the spirit of keeping things open source, and would feel bad if someone took columba and sold it, and it seems like a GPL based license is the best way to achieve that, but it does put other limitations around the whole thing that I'm not a fan of. That's why I've gone with MPL 2.0 for the time being, as it seems to be a decent middle ground. I've already spent way more time and energy thinking about software licenses than I care to and am much more interested in building cool stuff that works well.

I am also much more interested in making columba the best that it can be. Between the rapid pace of RNS development, and the challenges I've already outlined with iOS development, I do not have the time or energy to dedicate to making reticulum-kt a secure, safe, human verified implementation. I haven't even tested the -kt build on columba myself in ages. This alone is all the signal I need to know the best way forward for me is to stop releasing Columba with a -kt option. I'll post something on the readme of reticulum-kt as well, linking to this post, though at time of writing I still haven't decided if I'll archive it or not. Part of me really wants to go back and fix it one day, but I know that time is simply not on my side for this.

My AI use today and how I got here

I always knew that it was hypothetically possible that anthropic or openai could decide that columba was a risk or against their best interests to allow their models to be used on, but in reality it happened much more quickly than I anticipated. With the release of Fable 5, I was excited to point it at reticulum-kt to find gaps that Opus 4.8 had missed. And sure enough it happily found a huge list of gaps. I had it begin writing test cases to prove that they really were gaps (again by spinning it up along side RNS and probing from the outside) and while some of them were bogus, some of them were reproducible in tests.

It wasn't long into the session that was supposed to fix the first of these issues that anthropic flagged the session for cybersecurity risk and moved me back to opus. I could get around this for a time by starting new sessions, but this was a lot of wasted usage (fable was going through usage way faster than opus). This was pretty frustrating to me, as I'd been hearing all this (perhaps manufactured) hype around Mythos for months and was excited to try Fable. I had to recalibrate my expections and strategy after this.

There had been a number of other things anthropic had done in the months leading up to this (my memory is fuzzy now but the quality of the output always dipped in the week before a new model release, they had removed -p from the normal subscription based usage bucket and marketed it as giving new "usage based credits" that were actually a huge price hike and usage cut, they repeatedly blocked third party harnesses after openclaw came out, hermes, pi, etc.). It was just becoming something that was too frustrating to continue using. I'd seen results posted that the harness made quite a big difference on quality of output even using the same model, and I wanted to try other harnesses, but anthropic only wanted you to use claude code (with their subscription, which is dramatically cheaper than API based billing).

So I slowly switched from anthropic to openai, experimented with other harnesses, while diverting a good amount of time evaluating models I could run locally. Qwen 3.6 27b was pretty promsing, but I couldn't run it at over q4 unless I ran it on a unified memory machine that was painfully slow to use. So I returned to the hellscape that is the secondhand gpu market, and began waiting for a drop in gpu prices that never came. Meanwile I was using mostly gpt 5.6 sol, until yet again, it flagged me for cybersecurity risk.

Long story short, I'm now running qwen 3.8 27b at full precision for all of my daily work in columba, running on hardware I own. This has been great for me for a few reasons:

1. It gave me the chance to build another computer, which I always enjoy doing
2. It's not going to flag me for cybersecurity risk for daring to write code that uses encryption.
3. There are no usage limits (but there is a speed limit)
4. The model is roughly on par with opus 4.5 for coding tasks, which was really a sweet spot for me. It gets the basics right but isn't going to solve any big architectural problems that I couldn't on my own, and requires a similar level of steering and attention from me that the current frontier models don't need. This leads to me being more familiar with the code and details of the changes going into columba, even though it takes longer. The frontier models often one shot things I hand them these days, which is great for getting changes out the door and terrile for maintaining accountability and understanding of the codebase. Qwen also hasn't been RL'ed to hell and back for "long horizon work" or "your toughest biggest challenges."
5. It doesnt get mysteriously worse the week before a new model comes out
6. I can use whatever harness I want
7. I can only run 2-3 parallel sessions before it really starts to slow down significantly, which forces me to spend time engaging more instead of offloading everything to the machine. Single session is the fastest.

Wrapping up

Thanks for reading all the way to the end. It took me several hours to type this all out and think through how to phrase everything. Writing this has been in the back of my mind for a while, and I probably forgot something that I'd meant to say. Oh well.

Oh right, Pyxis

Yeah so I am still slowly making forward progress on pyxis. Pyxis is my very experimental t-deck plus firmware built on microReticulum. I have a number of things that I needed to build on top of microReticulum to get things working, but since C++ is quite outside my comfort zone, I haven't contributed any of the code upstream to atterman (though it is publicly available on my fork). I'm still working on getting nomadnet images to work well (and some other nomadnet rendering problems) but if you're feeling curious you can always build main and install it yourself. I recently fixed a bunch of performance issues and stabilized (well, relative to where it was before) the maps and location sharing functionality. Next release has a bit of a UI revamp to reorganize settings, make space for nomadnet, etc. Recent releases have fixed some issues with lxst calls.

The whole thing is really a toy for me though. I'd love to be able to hand it to a kid one day or use it on camping trips, but I really have a ton to learn about firmware development still before it can be considered anything better than a vibe coder's hopes and dreams. Expect it to crash from time to time. Don't hook it up to a public backbone and expect it to survive for long. Definitely don't depend on it for anything important.

Okay I think that's it

I am probably still forgetting something but I think this is long enough now. Thanks again for reading to the end, and for your support over the wild ride this whole thing has been for me. Thank you Mark for the gentle feedback, and for creating something so meaningful to so many.

- Torlando

Thanks so much @Torlando for spending the time and effort to share all of this! It was such an interesting read, and I really admire your honesty and openness in allowing us all to have such a deep look into the entire journey. Massive respect from me.

It's also a real treasure of experience, learned lessons and open questions, and that's valuable for all of us.

For me personally, it was super interesting to read about all your experiences with the corporate/proprietary models, their evolution and way into the work, both professionally and personally, and all the twists of that. Especially the Anthropic "security limitations", lol man, shit like that would have driven me mad. Apart from very limited mocking around with them, I've never actually deployed any of those for us in anything, so it was really quite fascinating to read. Glad you've found a setup that works better for you, and doesn't refuse half the time ;) I have a theory that the lower tps throughput of local models is, in the long run, really a net positive.

"Less haste, more speed"

I've read the above and would like to thank you for your work on Columba. I am running it on iOS and Android.
Interesting about Qwen 3.8:27b. I am running it on a Mac M2 Max w.64Gb and its refreshing to run tasks locally, albeit much slower as you say.
Onwards and upwards!

Glad to see you moved to local models, torlando. I haven't really thought about the iOS requirements. Reticulum-Go could work when I get to doing significant optimizations, but can't say that will be this year.

Fortunately, others have walked this path with Go before, like Tailscale (https://tailscale.com/blog/go-linker). One of my reasons for picking Go was all the open-source networking software using it and being able to see what they did.

Great write-up @torlando. I think it's funny how some of our experiences with AI are similar maybe even the same. Frankly, seeing some of your success with Columba, is what made me withdraw my application from f-droid. We had one interaction many months ago where I wanted to make sure our "reactions" had interoperability (along with MeshchatX and Ratspeak), and realized from reading your response that you were under a lot of pressure. The issues on your github were piling up, and I thought go myself "I'm not ready for this". Anyway, you are a superstar in my book and thanks for sharing your journey.

• thatSFguy