A quick bump of Wasat to v1.3.0. This follows on from the work started in v1.2.0, improving how hybrid mode works and also making host certificate verification information available in the response object.
The main improvement to hybrid mode is that it's now a little more discerning about when to fall back on TOFU mode. Only if the CA route fails due to an untrusted root or a self-signed certificate does it then fall back to TOFU; otherwise, an exception is raised.
I've also added verification information -- such as the method used and the fingerprint -- to the response object. This will be useful in Rogallo if I want to show in the display how the current server was verified.
As a handy diagnostic tool, I've also added the verification method and the fingerprint to the verbose output of the library's CLI command.
I've just released Wasatv1.2.0. This release aims to help out with a change I want to make in Rogallo in relation to certificate verification.
The issue is that, until now, Wasat offered either ca or tofu as verification modes. Meanwhile Rogallo was using tofu. Long story short: this meant that sometimes some sites looked like they were changing fingerprint way more often than you'd expect. The obvious solution here is to first check if a site can be validated via the ca route and, if not, fall back to the tofu route. This sort of change could have been made in Rogallo itself, but it would have been inelegant. Rogallo maintains a single Gemini client object, and the verification mode is baked in when the object is created. To move to this "try one way then the other" approach would have meant either maintaining two instances of the object, or tearing it down and making another each time we connected to a capsule.
Nah.
So the verify_mode of the Client has grown a new option: hybrid. When set to hybrid, the client will do the dance mentioned above: it will try and see if ca will work and, if it does, it will take that approach. If it fails, it will then fall back on pure tofu.
Out of the box, the defaults for the client are the same (it uses ca by default), and for the moment Rogallo is still hard-baked to tofu; given this, there should be no change in how things work when Wasat is updated. Now that this is up on PyPI, I'm going to pin Rogallo's use of wasat to >=1.2.0 and then, in an update, I'll swap over to hybrid. Hopefully this will result in a smoother journey when using sites like AstroBotany and Station.
ℹ️ Note
While writing this, I've noticed that there's one change I still need to make to this hybrid flow. I realised that, at the moment, any kind of CA failure will result in a fallback to TOFU. That's not ideal and needs refining. All part of the learning process.
PS: If you're wondering what happened to v1.1.0 of Wasat... there wasn't one. While preparing this release, I was also fighting with the fact that my MX Mechanical Mini keyboard seemed to be dying (and its battery does seem to be dying) and, because of that, managed to bump the version from v1.0.1 to v1.2.0. Oh well...
Rogallo has been updated to v1.3.0. This release adds an extra cosmetic feature to the Gopher support, and also extends what the internal command line is capable of.
Both of the changes come from suggestions made by -fab-, who's been an avid tester of Rogallo and a good source of pointers and ideas. The first change comes from a mention they made of how some Gopher clients will prefix links in a map with a three-letter ID to give a clue as to what the linked resource is. TXT for a text file, SND for any audio file, MNU for a link to a further map, that sort of thing. While I didn't add that when I initially added Gopher support, it did seem like a useful option to provide.
However, this being a "modern" TUI application, with access to a wee bit more than plain old ASCII, I thought I'd mix it up a little. By default, little "icons" or "badges" are shown with each link. So to take the examples given above, I'm using 📄 for a text file, 🎵 for an audio file, and 📁 for a menu.
Of course, some people might not want this, and this can be turned off entirely in the configuration file by setting gopher_show_type_badges to false. However, it might be that someone wants this, but not the emoji. That's where gopher_type_badges comes in. This is an association of Gopher types with text to use as the "badge". If three-letter all-ASCII "badges" are what you want:
The other feature springs from another suggestion -fab- made. This time it was the idea of adding direct command-line support for Gemini and Gopher search engines. This struck me as an excellent idea, but I got to thinking that it could be a little more generic than that. So I've added support for declaring simple command-line aliases. There's now a section in the configuration file1 called aliases. It's an association of a command alias and an expansion. The alias itself must be a single "word" of characters, and the expansion the actual command that will be used. It can be any other command-line command, or a URI. Anything that the command line can normally handle.
When the user types something into the command line, the input will be split on the first space. If the first half matches an alias, it will be substituted for the input, and the tail of the input will be made available as a parameter to the expansion.
There are three placeholders that do the expansion:
{q} -- The tail of the command quoted for use in a URI
{qp} -- As above, but spaces will be + rather than %20
{r} -- The raw, unquoted, tail of the command
I've probably done a bad job of explaining it. But hopefully the following default set of aliases will nicely illustrate it:
Given this, if you type ken test search, the actual command that gets input is gemini://kennedy.gemi.dev/search?test%20search. As I said, it's not just about search engines; you can also expand to other built-in commands. For example:
"whois":"!finger {r}"
Would have whois davep@plan.cat expand to !finger davep@plan.cat.
I feel this nicely solves the original request and adds an extra layer of utility to the internal command line.
Which I totally forgot to document when putting together this release. It'll come to the docs soon. ↩
A quick little update to GopherMap. v0.2.0 greatly relaxes the validation of incoming lines, being a lot less fussy about missing tab characters and also about fully empty lines.
I've got no desire for Rogallo to be harsh in this respect, so here's a much more relaxed version of GopherMap.
As of right now, the exceptions that are defined in the library are never raised. I've left them in for the moment because there's a window of time between this version being pushed to PyPI and Rogallo being updated (it does use the exceptions), where failure to supply them would cause Rogallo to crash under normal circumstances (nobody wants an unnecessary ImportError). Once I've updated Rogallo to pin a new lower bound, and removed use of the exceptions, I'll remove them from GopherMap.
Rogallov1.2.0 is now available. The main change in this release is the kick-off of support for the Gopher protocol.
As I've mentioned before: Gopher is kind of an unknown to me, in terms of actually using it. I'm aware of it, I've known about it ever since I first got on the Internet back in the 1990s, I have a half-recalled memory of dabbling with a Gopher client at some point back then, but I had no conscious knowledge of its workings. So, when I say "kick-off" above, I say it because I suspect there's going to be more work to do to make it work "just so".
However, right now, gopher:// URIs are supported in Rogallo.
The approach to supporting this is pretty simple: given a gophermap, as pulled from a server, Rogallo converts it into Gemtext and then displays it using the normal Gemtext viewer.
There is more to Gopher than just displaying the maps, of course: there's access to all kinds of resources. Where possible, Rogallo will display text-based resources within the viewer; all other kinds of resources are handed off to the operating system as they probably need applications and tools that Rogallo doesn't offer (viewing images, playing audio, etc).
Searches (item type 7) are supported, and when following such a link, you will be prompted for input, which will be used as the query.
Note that, for the moment, there is no support for extensions to the protocol such as Gopher+. Doubtless I'll look into doing something with this in the future; Rogallo's development is incremental and for me it's all about having fun (re)discovering new/old things.
There are two other notable changes in Rogallo v1.2.0:
I've modified the ordering of entries in the history search so that the items appear in most to least recent order. While being able to type in things to find back a location is the primary use, I also found I was often pulling it up to find something I'd visited very recently.
I fixed the "view source" status being sticky during navigation. If I was viewing the source of a location, and then navigated to another location (by using the Back command, for example), that other location would also show the source. The status is now reset every time you navigate to somewhere else.
Having spun up Port70 as a support library for my effort to add gopher support to Rogallo, the next thing I needed was some code to parse the "gopher map" responses that you get back from Gopher servers. While this could have been some code in Rogallo itself, much like with Gemtext, it seemed sensible to put it in its own library so it could be useful elsewhere.
Because Rogallo heavily relies on MIME types to make decisions about what to do with content, each ItemType has a best-efforts-guess mime_type associated with it. This will make it pretty straightforward for me to decide if a resource from a Gopher server is something Rogallo can display.
It was, of course, inevitable that this would happen. After spinning up Port79 so that I could add finger support to Rogallo, it made sense that I start to think about Gopher support too. So here we go: Port70, a similar library for async interaction with Gopher servers.
This is going to be a bit of an adventure for me. While I'm long familiar with the existence of Gopher, and I'm fairly certain I used a client once or twice back in the 90s, I've never really had dealings with the protocol so know very little about it. Which is a good thing: something new (old?) to learn.
My plan with this is to add the GopherURI class to the list of URI types that Rogallo understands and handles and then provide a method of displaying and navigating the result. I think the cleanest and easiest way of doing this will be to add some code that transforms a menu response into gemtext and then just let the viewer widget display it as normal; each of the links in the menu being turned into gopher:// URIs.
This should be fun to play with. I'm looking forward to pulling it all together.
I've just bumped Port79 to v1.0.0. There's no significant change in this release, other than the addition of the usual dunder-based metadata that is common in Python libraries; somehow I'd managed to leave it out in the last couple of releases.
Now that I've successfully added finger support to Rogallo, and the library is working out well, there didn't seem much point in letting it hang around in zero-point-whatever-land.
On the off chance that someone else does use Rogallo, and needs help getting to the bottom of some sort of issue, I thought it might be useful to add a diagnostics command to the CLI. Right now it's pretty simple, just dumping some version and environment information.
This was something I was interested in adding, and a couple of people have already requested it, so Rogallo now has finger support. This has been added in a couple of ways. The first and most obvious is that finger: URIs are now natively supported in Gemtext content. So now if you follow a finger:// link you'll see the response in Rogallo itself.
The other method is to use the new !finger command that has been added to the application's command line.
Of course, in the command line, you can also just enter a finger:// URI if you wish, which I guess is a third way of doing it.
Finger URIs are recorded in the history, and can also be bookmarked.
This was also something I was keen on doing, and then someone else happened to ask for it: support for swapping out to an external editor for writing user input. While the current mechanism is fine for entering a one-liner -- or composing a very short message -- a proper editor (for me that's ideally one with the ability to check spellings) is generally going to be far more useful for a longer body of text. So, with this in mind, the internal editor can now optionally swap out to your text editor of choice.
If you have either VISUAL or EDITOR set in your environment (VISUAL beats EDITOR), Rogallo will let you swap to it by pressing F3 in the internal editor. You can also override that choice by setting external_editor in the configuration file.
Personally, I'm finding this is working really well with emacsclient. From now on, I'm going to find writing content in Geminispace a lot easier.
Now that I've been wandering around Geminispace some more, I've noticed that a common use of pre-formatted text is for logos, ASCII art, that sort of thing. Generally, the sort of things that are best presented with the background the same as the surrounding text. A different shade of background is fine if showing code and stuff, but I feel that this:
looks better than this:
To this end, I've modified the pre-formatted text rendering so that, by default, if pre-formatted text has no alt-text, the background is the same as the surrounding text. On the other hand, if it does have alt-text (and so is likely the name of a programming language, which implies syntax highlighting, which in turn implies you want it to stand out), it isn't blended with the rest of the text.
If your preferences differ from mine, you can control this with the new blend_pre_formatted_with_background configuration file setting. It takes a list of alt-text strings that should be blended. By default it looks like this:
"blend_pre_formatted_with_background":["",]
That is, by default, it only blends empty alt-text pre-formatted text. As it happens, Station uses alt-text for the logo and the user image, but I'd like them blended in too, so I'm running with this:
The last change is a small cosmetic fix to mouse interaction with links. When the mouse cursor is over a link, there should be a hover effect (that is, the background should change colour). This wasn't working if you had link stripes turned on. This is now fixed.
