Now that I have it working at about the same level of reliability as the other plugins in the Newsboat repo I’ll pull out the dependency on dotenv and just tell the would-be consumer “get this credential into an environment variable, hardcode it, or do something else that feels safe to you.”

For myself, I’m weighing a couple of options because I’d like to do a little better than having a bunch of credentials sitting around in the plain.

Over the years I’ve handled this with mutt by combining gpg with mutt’s source config command:

1. Make a very minimal rc file in mutt’s config syntax that sets your user and password:

          set imap_user=you@example.com
          set imap_pass=yourimappassword1234

2. Encrypt that file with gpg:

   gpg -r yourkey@example.com –encrypt passwordfile

3. Use mutt’s source directive in your muttrc to decrypt the file on the fly and read in those two directives:

   source “gpg -d ~/.mutt/passwords.gpg |"

If you have gpg set up correctly, you’ll get a key authentication prompt when you run mutt. The credentials are never stored in the plain on disk, and you’ll get a gpg password prompt every now and then if you have other stuff going on, such as multiple accounts that each need to periodically source that config when you change between them. mutt’s source is just “do whatever is in this file,” same as zsh’s, so I eventually landed on a way to do the same thing in a shell environment:

$(gpg –decrypt ./setenv.sh.gpg)

That just decrypts setenv.sh.gpg and runs the commands inside, which can be just setting a bunch of environment variables in the current shell environment. The data is never decrypted to disk.

That seems like a good general solution that covers a lot of drive-by security scenarios.

In the process of working that out, I wondered about 1Password’s CLI tool. The few times I saw it mentioned the demos were for secrets management, not retrieval, but I took another look at the docs and it does have some interesting provisions for getting your secrets out of 1Password from the CLI.

Basically, when you use the op command’s run argument you can tell it to source in some environment variables from a .env file that uses op’s internal URI scheme to pull credentials out of your vault. An example resource reference looks like this:

op://Personal/Linkding/password

If you put that in an env file with a variable assignment, the op command can source it and pass it along to a shell command. So:

op run –env-file="$HOME/.env” – ~/bin/linkding.rb

… reads from a file that looks something like this:

LINKDING_USER="op://Personal/Linkding/username"
LINKDING_TOKEN="op://Personal/Linkding/credential"
FRESHRSS_USER="op://Personal/FreshRSS/username"
FRESHRSS_PASS="op://Personal/FreshRSS/credential"

… and supplies the linkding script with a value for this line:

token = ENV[‘LINKDING_TOKEN’]

If you’re already auth’d into 1Password and you’ve enabled integration between the CLI tool and the desktop app, then you don’t have to do anything. If you need to re-auth your 1Password instance, you’ll get a biometric prompt. If you’re ssh’d into a remote host where you wouldn’t get the biometric prompt, you can bypass that by setting OP_BIOMETRIC_UNLOCK_ENABLED=false but you’ll need to explicitly auth the 1Password CLI tool from the command line. It doesn’t seem to just fail over to a CLI auth.

So, handled the 1Password way, your .env file could remain unencrypted, but you’d probably be best off aliasing any scripts or commands you run where you want the op tool to interpolate your .env file.

It’s a little more cumbersome but maybe there’s benefit over the long haul from knowing that you just have to keep credentials in 1Password and can reference them elsewhere instead of maintaining an encrypted .env file. It’s also nice to have a biometric prompt or system auth vs. using gpg keys, which require you to have another password on hand (at least until 1Password quits punting on a gpg agent to pair with the ssh one).

For now I’ve only got enough stuff connected this way to use 1Password with FreshRSS and my Linkding plugin. Newsboat allows you to set your RSS service’s password with output from a shell command, so I’ve got that set to:

freshrss-passwordeval “op read op://Personal/FreshRSS/credential”

If I’m auth’d into 1Password, great: It just runs and sets the credential for NewsBoat. If I’m not, great as well: It just runs and tosses up a biometric prompt before proceeding.

I’m also using the env file pattern for Newsboat, for my bookmarking command:

bookmark-cmd “op run –env-file="$HOME/.env" – ~/bin/linkding.rb”

That’s because I don’t want to write my Linkding plugin to require any particular infrastructure. It just wants an environment variable, which is supplied by wrapping the script in the op run command with an –env-file switch. If someone wants to take the script and use another way to get the variable into their environment, or just decide to take their chances and hard-code it because they’re comfortable with that risk, they can. If I ever stop using 1Password I can similarly just figure out a new secrets backend and may be able to avoid rewriting a bunch of utility scripts if I keep using this approach. If I want to use one of my scripts on a host where I don’t have 1Password, well, there are other ways.

Update: I wondered about that mutt setup I have and ended up seeing what would happen if I replaced the whole “load mutt, source a gpg-encrypted file” thing with simple 1Password resource references. It works pretty well. If you’re signed into 1Password, it just works. If you’re not, you get a biometric prompt:

set imap_user=`op read op://Personal/MuttFastmail/imap_user`
set smtp_pass=`op read op://Personal/MuttFastmail/smtp_pass`
set imap_pass=`op read op://Personal/MuttFastmail/imap_pass`

Same caveats as with everything: If I ever end up wanting to use my mutt config on a machine I can’t put 1Password on, I’d need to go back to my old gpg file pattern.

Newsboat is pretty cool! It’s a plaintext RSS reader that has strong affinities for mutt in look and configuration.

Like mutt, it might not crowd out everything else in the toolbox but it can help you burn through the subscription list and triage even if you have more comfortable ways of reading the content you process.

It also has built-in filtering. If you’re using an RSS provider that already does that, e.g. FreshRSS or Feedly, that might not be super valuable, but it’s easy to make a killfile either way:

ignore-mode display
ignore-article "*" "link =~ \"/ducks/\""
ignore-article "*" "link =~ \"/advice/\""
ignore-article "*" "link =~ \"/nfl/\""
ignore-article "*" "link =~ \"/beavers/\""
ignore-article "*" "link =~ \"/blazers/\""
ignore-article "*" "link =~ \"/highschoolsports/\""
ignore-article "*" "link =~ \"/entertainment/\""
ignore-article "*" "link =~ \"/realestate-news/\""
ignore-article "*" "link =~ \"/food/\""
ignore-article "*" "link =~ \"/hawks/\""

Scripting the Linkding API to make a bookmark function for Newsboat

If you like reading longform plaintext maybe Newsboat is all you need. I tend to treat RSS as a two-step process: See an interesting thing, send it to some sort of RIL or bookmarking service. Newsboat has a bookmarking function you can customize with your own scripts. It just passes the article URL, title, description, and website description to your script, which has to talk to whatever API. There are a bunch of examples in the Newsboat contrib directory for things like Pocket, Pinboard, and Evernote. No Linkding, but the Linkding API is simple enough.

Could be simpler but I bounced off of net:http in my formative years:

#!/usr/bin/env ruby

require 'httparty'
require 'json'

linkding_uri = "https://links.puddingtime.net/api/bookmarks/"

# Get your Linkding API key from Settings > Integrations

token = ENV['LINKDING']

link_url = ARGV[0]
link_title = ARGV[1]
description = ARGV[2]
website_title = ARGV[3]

params = {url: URI(link_url), title: link_title, website_title: website_title, unread: true}
headers = {'Content-Type' => "application/json", 'Authorization' => "Token #{token}"}

resp = HTTParty.post(linkding_uri, body: params.to_json, headers: headers)

I keep having to reinvent this every few years, and I always stitch it together from assorted sources, mostly because Google sort of shifts around now and then. So:

• Given a Gmail account with IMAP access turned on
• Given a Fastmail account using IMAP
• Given mutt, with your configuration in ~/.mutt and with muttrc and macros files.
• Given a working gpg config you can use to encrypt/decrypt

There are all sorts of ways to handle mutt config for assorted providers. The examples here are working right now, in early 2024. They probably have bits of cruft and lint because my config has been a work in progress since some time in the late 20th century.

Overview

You’re making profiles to do this: One for each of your accounts that will hold account specific config information. If you currently have a monolith config in mutt, you can lift a lot of stuff out of it and move it into a profile, then source the profile in your main muttrc.

You’re also going to make and encrypt a credential file for each account. Some people do this all in one file and use account hooks to make sure imap_user, imap_password and smtp_password are set correcctly depending on the account you’re operating in. I chose to make a file for each account.

You’re going to make macros that source the profiles when you want to switch between them.

0. Pre-config with Gmail and Fastmail

I’m not going to go into a ton of detail here:

• Gmail needs to have less secure app access turned on. Find it in your account settings. If you’re doing this for a work account, it may be your admin hasn’t enabled this. Have fun fighting city hall, in that case.
• If you have a GSuite admin, they need to have enabled all IMAP clients, not just OAuth ones.
• If you have 2FA turned on with Google, you will need to enable an application password.

For Fastmail:

• You need to have an app password set up for mutt. Settings -> Privacy and Security -> Integrations -> App passwords

1. The profile files

Make profile files for each of your accounts. I name them workplace.profile, fastmail.profile, etc. It doesn’t matter there’s no required convention. It’s a good idea to use the first one as the template for the second one.

This is an example of my Fastmail profile. Note line 6:

source "gpg -d ~/.mutt/passwords.gpg |"

That’s where your credentials will come from. I’ll show that file next.

# -*- muttrc -*-
# Mutt sender profile : personal/default

unset folder
set smtp_authenticators = 'gssapi:login' # fastmail needs this
set imap_authenticators = ''
source "gpg -d ~/.mutt/passwords.gpg |" 
set spoolfile = "imaps://imap.fastmail.com"
set folder = "imaps://imap.fastmail.com/INBOX"
set postponed="+Drafts"
set hostname="yourdomain.com"
set signature= "~/.mutt/personal.sig"
set from= "Bob Jones <bob@yourdomain.com>"
set realname = "Bob Jones"
set smtp_url = "smtps://bobjones@fastmail.com@smtp.fastmail.com:465" # use your fastmail username, not your email address
set imap_user = "bobjones@fastmail.com" # use your fastmail username here, too

# set the status to show which profile I'm using
set status_format= "-%r-Fastmail: %f [Msgs:%?M?%M/?%m%?n? New:%n?%?o? Old:%o?%?d? Del:%d?%?F? Flag:%F?%?t? Tag:%t?%?p? Post:%p?%?b? Inc:%b?%?l? %l?]---(%s/%S)-%>-(%P)---\n"

unmy_hdr *

my_hdr From: Bob Jones <bob@yourdomain.com>
my_hdr Organization: yourdomain.com
my_hdr Sender: Bob Jones <bob@yourdomain.com>
my_hdr Return-Path: <bob@yourdomain.com>

# clear the existing mailboxes list
unmailboxes *

# load up mailboxes appropriate to this profile
mailboxes + "=Spam"
mailboxes + "=disposable"
mailboxes + "=Newsletters"
mailboxes + "=Sent"
mailboxes + "=Archive"

2. Make credentials files

For each account, you need to make a file for your credentials.

set imap_user=bob@bobjones.com
set imap_pass="klatu barada nikto"
set smtp_pass="klatu barada nikto"

Name it whatever. passwords-accountname works.

Once you’ve created the file, encrypt it with gpg:

gpg -r your-gpg-key@yourdomain.com -e passwords-fastmail

Test it:

gpg -d passwords-fastmail.gpg

Then shred the plaintext original:

shred -u passwords-fastmail

Make sure that your profile (from the previous step) is sourcing the gpg file in line 6 of my example, e.g.

source "gpg -d ~/.mutt/passwords-fastmail.gpg |"

3. Do a quick mid-config check

Might as well test it now. You can do that by sourcing one of your profiles in your muttrc:

source ~/.mutt/fastmail.profile

When you run mutt the first time in this login session, you should get a gpg prompt for your credentials so mutt can decrypt your password file and use it to log in.

If it’s working, now’s the time to make your second profile and credentials files using the above steps since it’ll be good to know what they’re all called for the next step, which is making macros.

4. Make macros

I keep my macros in their own file under ~/.mutt just to keep things modular. You can put these in your main muttrc. Whatever you prefer. If you have a separate file, make sure to source it in muttrc:

source ~/.mutt/macros

Now add something like this for each account:

macro index .cf '<sync-mailbox><enter-command>source ~/.mutt/fastmail.profile<enter><change-folder>!<enter>'
macro index .cg '<sync-mailbox><enter-command>source ~/.mutt/google.profile<enter><change-folder>!<enter>'

That just does one last sync, then sources your profile, then changes folders to the inbox of that profile.

Restart mutt. From the index, if all is working correctly, the macro .cf will source your fastmail.profile and the macro .cg will source your google.profile file (both of which also source/decrypt their respective credential files).

5. In conclusion

Once it’s all wired up and running, you should be able to switch back and forth between accounts with just a few seconds of latency as the inbox syncs on exit and the new inbox syncs on login.

The pleasures of mutt

I went on a mutt revival kick early last year. It remains a land of contrasts. I never end up sticking to it 100 percent of the time but instead prefer to use it as a quick triage tool: It’s easy to make macros and keybindings that speed up inbox processing. Sometimes it’s easier to just bail out to the web mail interface, but during the day it’s helpful to just burn through the inbox never taking my hands off the keyboard.

mutt scoring and color treatments

One last thing, I guess, since I’m documenting stuff. One of the reasons I like mutt for triage so much is my ability to add a little visual treatment to messages based on their scores. That makes it easy to see what in my inbox has more priority.

I’ve got this little script in my ~/.mutt:

#!/usr/bin/env ruby

require 'mail'
require 'tempfile'

# Wants a +/- integer, e.g. +20
score = ARGV.first

score_file = "#{Dir.home}/.mutt/scored"

msg = Tempfile.new('msg')

msg.write($stdin.read)

mail = Mail.read(msg)

from = mail.from.first

File.open(score_file, "a") { |f| f.write "score ~f#{from} #{score}\n"}

msg.close

msg.unlink

And I’ve got these macros in my ~/.mutt/macros file:

# Score messages
macro index,browser .sp "<pipe-entry>~/.mutt/mailscore.rb +5\n<enter-command>source ~/.mutt/scored<enter>" # score sender +5
macro index,browser .sP "<pipe-entry>~/.mutt/mailscore.rb +20\n<enter-command>source ~/.mutt/scored<enter>" # score sender +20
macro index,browser .sm "<pipe-entry>~/.mutt/mailscore.rb -5\n<enter-command>source ~/.mutt/scored<enter>" # score sender -5
macro index,browser .sM "<pipe-entry>~/.mutt/mailscore.rb -20\n<enter-command>source ~/.mutt/scored<enter>" # score sender -20

And I’ve got a few lines in my ~/.mutt/colors file:

color index cyan default "~n 0-2 !~p"
color index magenta default "~n <5"
color index brightyellow default "~n >15"
color index brightred default "~n >19"
#

The macros pipe a given message into the script, the script extracts the sender, and the script writes a line into my ~/.mutt/scored file. Then the ~/.mutt/colors file (which you need to source in muttrc) assigns colors to certain scores. I have a few other rules in ~/.mutt/scores, as well:

# Date-based scoring penalties -- older things fall down
score ~d>3d -1
score ~d>7d -3
score ~d>14d -10

score "~O" +10 # old = +10 so I don't miss it
score "~F" +20 # flagged = +20 so it stays in the interesting view for a while, even if old
score "!~p ~d>7d" -10 # not for me directly, getting old, let it fade away
score "!~l" +2 # to a known list, give it a bump

I got a boom for my USB shotgun mic (a Rode VideoMic GO). It mounts on the back of my desk and swings in and out of place between calls. It sits about eight inches away from my face, but just off camera (yay relatively tight 23mm crop) and the sound quality is sooo much better than when I had it mounted in my X-T2’s hot shoe. Much more presence and bass, much less reverb. Okay. Time to start a podcast. I can feel it.

tmux alternative

Zellij is a terminal multiplexer ala screen or tmux, but it’s got a nicer onboarding ramp than either thanks to a decent menu that exposes most of what you need and out-of-the-box UX touches.

Through the holidays

We had a pretty good holiday season this year. Ben was home from his first term at UofO, and we had a quiet couple of weeks with few obligations. Work was pretty quiet, too: We had a major system change slated for the interim week, then the vendor backed out, so there was a little bit of “shrug, I guess there’s this paperwork to catch up on,” which is a fine way to spend that week.

It’s good to be almost on the other side: We have a balance day off this Friday, so this will be a three-day week, then back to normal next week.

Just as good as Todoist for my purposes, and with a little more personal affection toward it, is definitely Remember the Milk. It also has a CLI that allows for task manipulation, etc. It also uses RTM’s advanced search syntax, so you don’t have to have a preexisting filter, as you would in Todoist, to query upcoming todos with due dates only:

rtm lsd -d 4 NOT due:never

(List due items no more than 4 days out, exclude things without due dates)

Its output also includes index numbers, so once I invoke my near-term todos, I can act on them from the command line, e.g.

rtm due 07 tomorrow

… which changes the due date of item 7 from the list to tomorrow.

I think this may have put to bed my interest in exploring nb. I spent some time poking at it, but the question, as always, comes down to “how does this thing handle mobile use cases?” For todos, I need a little more than the sort of web publishing lashup I made for my Denote notes.

Vampire Survivors

I am not sure what compelled me besides maybe the sale price, but I gave Vampire Survivors a go and I’m hooked. It’s a rogue-like bullet hell thing where you’re running around being chased by hordes of undead, slowly acquiring weapons and powerups that eventually turn you into a killing machine.

It was disorienting at first, because you don’t do anything besides move around. All your weapons fire or deploy themselves, and your only real input into the process is the direction you face the character. Live long enough and you’re eventually emitting magical energies or deploying roaming weapons of mass destruction, killing the oncoming demonic hordes by the score. Sometimes there’s a turkey you can eat to get life back.

It’s an intense game, but it’s not really fast. I think that’s what I like about it. Your character doesn’t move at a very high speed. You just sort of walk around, trying not to be touched by the monsters. If you’re lucky you happen across one of the aura weapons that just passively kill anything that gets close. When you die, you can spend your gold on incremental improvements to your character that allow you move a little faster, regenerate health, widen the radius of your weapons, do more damage, etc.

It’s very simple to play and very easy to put down and pick back up.

Substack

I wish people that I appreciate and who are not Nazis, or interested in helping Nazis, and who are also on Substack, would get off of it. The company did itself a favor paying the advances it did at its founding, because I know of a few writers who have been very transparent about how much space that gave them to branch out on their own, establish or rebuild writing careers, and find an audience.

I always wondered how long it would take for attention to turn to it, and what it would take. Honestly, I think it is a refutation of the Woke Apocalypse Doomsaying Community that it took this long and such an odious provocation to finally generate that kind of awareness. There has always been complaining, because left libs were never going to be okay with a platform that provided a home for the likes of Bari Weiss, Matt Taibi, and assorted other “heterodox” types, but it took honest-to-God Nazis – and the fact that Substack has decided their money spends just fine – to draw prolonged attention.

A while back, fresh out of years and years doing online content, I gave a thought to providing something Substack-like: I had the technical know-how for a lot of it, had done some time putting together newsletters and turnkey premium content, and had a good idea of what would work for content types. I didn’t have any idea how to scale it all, or how to draw the line between “good enough” and “feature rich” in a way that would make much money. I’m just noting that because the quandary facing people who signed up and are now making a living from their work on Substack is real. There are parts and pieces laying around that they could pick up and use to cobble together a similar suite of blog, newsletter, and podcast tools; but the discovery part – the marketing problem, especially given the current realignment going on with social media – is going to be fraught even if one does have the wherewithal to rummage around in the parts bin of publishing platforms, payment processing, etc.

This is a tougher situation than, I dunno, a well-off tech worker who just can’t kick their X habit. It is hard to make a go of it as a writer. It would be hard to pull up stakes and move on.

I wouldn’t mind being a little more current and capable than I am today, because there would be some social utility and satisfaction in helping people get out of this situation.