Another little update to Wasat, this time bumping the version to v1.11.0.
After this morning's change, I made a start on the work I wanted to do on Rogallo and quickly realised that most of what I had planned was better done in Wasat itself. The short version is: rather than maintaining a just-this-session ignore list in the application, it made more sense to handle this in Wasat.
So this release adds an ignore_security_error method to the client that lets you -- for the current session -- ignore a particular type of error for a given host/port pair. This makes for a lot less work needing to be done by the application making use of Wasat. Now it's just a case of1:
Since getting into Gemini, one of my daily rituals has been to tend to my plant in AstroBotany. This morning, when trying to visit there with Rogallo, I was greeted with this:
In other words: the certificate has expired1. At this point, the error dialog isn't that useful. It's pretty much designed for dealing with capsules that are using self-signed certificates -- where TOFU is being used and so it would normally make sense to just forget and re-establish trust. With an expired CA certificate, the act of forgetting does nothing, it'll just fail again.
While it's technically fine to simply refuse to progress, in this case, it's not exactly friendly to the user. What would be sensible would be to allow an "Ignore" option. This would, I imagine, ignore the problem for the current Rogallo session -- ideally with some sort of indication that the capsule is suspicious at the moment. Also, the dialog that gives you this option should show all the certificate details so the user can make an informed decision.
The issue here is that, until now, Wasat has dealt with security-type problems by raising a single SecurityError exception. Aside from dumpster-diving the description in the exception, there's no way of knowing the nature of the security issue. v1.10.0 addresses this by adding and raising many different exceptions:
CertificateExpiredError
CertificateNotYetValidError
CertificateRejectedError
CertificateRevokedError
CertificateUntrustedError
FingerprintMismatchError
HostnameMismatchError
All of these inherit from SecurityError to maintain backward-compatibility.
While this change doesn't alter the way that Rogallo handles this situation right now, it does at least set me up for tackling the work I have planned.
By the looks of things it expired at 2026-10-26T01:52:07+00:00 ↩
I've just bumped Rogallo to v3.2.0. This release has one small new feature and one wee bug fix.
The new feature is something I found myself wanting a short while ago. I was copying some URIs and then turning them back into Gemtext links in another document; after doing that a few times, I realised that it might be handy to extend the "copy URI" facility in the viewer so that there's a "copy URI as Gemtext" version. To this end, I've added gemtext_link.copy_link_as_gemtext as a viewer widget binding, bound to Shift+c by default.
The fix is a small one to how MIME type checks are done. In one particular case, Rogallo wasn't stripping off any parameters where it should have. This is now fixed.
Right from the start of the development of Rogallo, I ensured that any MIME types that the application couldn't handle were correctly handed off to the operating system, to allow it to work out what to do. While it is possible for me to do some work to allow images inline -- something I might explore at some point in the future -- Rogallo doesn't currently support this and, accordingly, when faced with image/jpeg or image/png, etc, it delegates to the wider environment.
The problem, of course, is that the user might not have a tool in their environment that's capable of taking over the duties of downloading an image from a gemini URI and displaying it. So the next best thing is that Rogallo itself offers to download the file for you. With v3.1.0 this is now an option.
If you encounter a MIME type that hasn't already been marked for always opening in an external tool, there's a new Download button.
If selected, you'll be asked for a location to save the file.
To augment this, I've also added downloading support for links in the viewer. It might be, for example, that you've already marked image/jpeg and image/png as MIME types that should always be handed off to the operating system (perhaps you have a GUI-based client such as Lagrange or Major Tom installed and it's configured to pick up the URI and handle it). In that case, you'd never be shown the dialog that would allow for downloading. So now, on the occasion that you do want to download within Rogallo, you can navigate to the link and press d. The download dialog will then appear, and you can save the content of the link that way.
For now, at least, the download process is pretty simple. It follows the same approach as acquiring the content of a URI for display purposes, but instead writes it to the file you picked. There's no "download manager" or similar and no sticky "download directory". These are things I might consider adding in the future.
It's been a while since I last published an update to Rogallo. In part this is because I've had other distractions, but also in part because I've not had a huge need to add any new features of late. For the most part I feel Rogallo is "done"1.
I haven't, however, been doing nothing with the code. On and off, over the last handful of weeks, I've been addressing something that I've wanted to tidy up since the early days of development: application configuration. The majority of my Textual-based applications use a simple JSON configuration file, and that's generally good enough. When I started Rogallo I used the same approach. Rogallo has since grown quite a lot and there's much that can be configured and so the "honking great pile-o-JSON" approach was starting to feel quite untidy.
So Rogallo v3.0.0 addresses this. The headline change is that the single JSON file has been replaced with a number of focused YAML files, and some items that were in the original configuration file have been moved out to either the data directory or the state directory, depending on their purpose.
Now for some details on the changes.
❗ Important
There are a lot of changes to how Rogallo is configured. As is mentioned at the end of this post, Rogallo will make a best effort to migrate your old configuration to the new format. However, as a precaution, you might want to think about making a backup copy of your configuration.json file before upgrading Rogallo.
As mentioned above, whereas before Rogallo kept all of its configuration in a single file, it now looks to a number of different YAML files that focus on a different aspect of configuration. These include:
Rogallo's design is based around the idea of some "actions" being application-wide commands, and some actions being UI-control-specific. As I worked through the configuration changes I decided that it was time to "demote" some application-wide commands to either being UI-control-specific bindings or just simple configuration properties. With this in mind I've removed the following commands:
From the very start, Rogallo has supported some degree of control over keyboard bindings. As mentioned above, there's a split between "application-wide commands" and "UI-element-specific" actions. Until now it's always been possible to configure the bindings for the former, but never the latter.
In other words: you could always configure the binding for the HandOffToOperatingSystem application command (hands the URI of the currently-viewed document to your OS), but you couldn't change the in-viewer binding for the o key, which opens the URI of the focused link in the OS.
Not directly a configuration setup change, but something I noticed while doing the work, was the fact that Rogallo (and the underlying Gophermap library) didn't handle PNG and RTF item types. They're now directly supported.
I believe all of the above changes make it easier to configure Rogallo, and more importantly easier to backup and share the configuration. Technically all of this is one huge breaking change -- everything that was in configuration.json now lives elsewhere. However, I've added some code to Rogallo that detects when you still have a pre-v3.0.0 configuration active, loads up the values, creates the new files, and then renames the old file to configuration.migrated.json. As mentioned near the start of this post, you might want to think about making a backup copy of configuration.json before upgrading.
One last big thing I do want to add is support for tabs. Still to come. ↩
As the name says: a collection of "weird little guys" of the FOSS and adjacent worlds. Massively subjective, of course, but I don't think I've seen one (that I know of) that I disagree with yet.
Yet another smolweb protocol, and yet another derived from or related to Gemini. I doubt I'll do anything with this one (Rogallo supports enough as it is for now), but it's worth keeping a link to it.
I build enough applications using Textual; it might be interesting to play with a framework that works on all sorts of platforms (as opposed to just in the terminal).
I've not used DO for a while now, but I have been thinking about setting up a small host again so I can play with Gemini and Gopher. Having used DO in the past, they were at the top of my list.
I've just made a small update to GopherMap. While doing some work on Rogallo I noticed that, somehow, I wasn't showing a type "badge" for PNG files (p). I spent a moment or two trying to figure out what was wrong with the code in Rogallo, and then realised that I'd managed to miss out both PNG and RTF files in GopherMap itself.
I've released Rogallov2.4.0, which contains two new features.
The first is the addition of a feature related to the Gemini Protocol, and it's something I've been meaning to add for a wee while: a trusted host browser/manager. It's a simple enough idea: you might want to have a look at all the host/port pairs that exist in your trusted hosts list and, perhaps, revoke the trust for one or more.
From the dialog you can either visit the host/port combination (perhaps you got curious about what you've trusted in the past and want to see what was there), or you can forget the trust. This also somewhat follows on from work done in Rogallo v2.1.0, except rather than having to make the decision when you visit a capsule, you can review all the capsules you currently trust.
If this seems useful, it's called up with the new BrowseTrustedHosts command, bound to Ctrl+Shift+t by default.
The second new feature is something that's been on my TODO list for quite a while, and has mainly been sat there because I wanted the viewer widget in the application to settle down a bit before I tackled this. I'm talking here about in-viewer search. It's a simple enough requirement, but one that's not that straightforward when you're dealing with views of different kinds of text files, views of the source of such documents, and also having to handle things like embedded ANSI escape sequences.
The work is now done, so if the viewer itself is focused, you can press Ctrl+f, enter some text to search for, and then press Ctrl+n to keep moving through all the hits. Once you hit the last match, you'll be told there are no more matches, but then the search will start again from the top.
You can also cancel an ongoing search with Ctrl+Shift+f.
I'm glad to finally get this added to Rogallo as it's a feature I've been finding myself needing on a good few occasions.
First up, there's a small fix. The other day I discovered Scriptonite. While looking at the examples I noticed none of them worked with Rogallo. This struck me as odd because the whole point of Scriptonite is that it all happens on the server-side; nothing on the client-side should affect how well it works.
It turns out that Wasat had a bug when it came to slicing and dicing Gemini URIs, where parts of a URI that followed a ; were being lost. Somewhat amusingly, I didn't even need to do any work on a fix because it had already been taken care of in the branch that existed to support Titan.
The point here being: as of v2.3.0, Rogallo now works fine with the Scriptonite examples.
As I mentioned, the main change in this release is support for the Titan protocol. It's been on the TODO list for a wee while, partly because I was struggling to follow the idea of it, and also partly because I'd not played with it and just didn't see the purpose. The other day I sat down and properly dived in and it finally all clicked.
With v2.3.0, if you now visit a titan:// URI, you will be presented with a rich input dialog. It is a tabbed view, with one tab being for text input/upload:
and the other being a file attachment and upload:
As per the Titan specification, there is support for setting the MIME type for the attached data. If using the text view, this will always be set to text/plain. If using a file attach/upload, you have full control over it, but it will default to the best guess based on the file selected.
There is also support for entering an upload token.
As well as supporting the core Titan specification, I've also added support for the proposed ;edit extension. This means that it is safe to enable Titan-based editing on bbs.geminispace.org, making it easier to modify text you've already written.
One final change in this release of Rogallo also relates to user input. I've given the Gemini-based input dialog an overhaul. Originally this was, by design, as simple and as bare-bones as possible. It was simply a free-text input box that would grow as you added lines, and the prompt from the server was shown as a title in the border of that box. While testing out editing on BBS, I realised that this doesn't always work so well; most of the time the prompt would get truncated.
Not a great user experience. The redesigned input box works more or less the same, but now ensures that the prompt is fully visible.
Between this change and the new Titan edit/upload dialog, I feel Rogallo is now in a good position to act as a near-zero-compromise daily driver when it comes to wandering around the small web.
I guess adding tabs will get it closer to zero. Perhaps in-terminal image viewing. Okay, perhaps a sprinkle of http(s) support too? Also...
The work to add Titan support to Rogallo is going well, and I've been able to test it out fine on bbs, doing additions of "long text" and performing file uploads. In doing so, though, I was reminded that there is a proposed "edit" extension to Titan, which is supported there (and I believe on a couple of other capsules too). That got me thinking...
Wasatv1.9.0 is now available, which adds support for this extension. Of most use is the is_edit property which has been added to TitanURI, giving a well-defined approach to testing whether a Titan URI is for editing a resource. The Client class has also grown an edit method to handle the request for the raw content which will then be used as the basis for a subsequent edit by the user, before being uploaded.
All of this, of course, pushes back the work I'm doing on Rogallo, just a little. As I said above, the Titan support is pretty much there and working, but now I want to try and really dial it in and get it working "just so". While the edit support is probably pretty niche, it seems worth adding and, I hope, might delight someone one day when they try it out and it "just works".
