Agaetr and Orindi – Working With RSS, email, and social media

Okay, that sounds a little grandiose for what I’ve actually done here. I’d like to introduce you to two projects that I put together to work with RSS feeds, email, and social media. (Both are written for *nix; you might be okay with the shell on OS X or using WSL on Windows.)

Both are written and operate on a "It works for me" kind of principle. I’ve made efforts to make sure it works and the installation instructions are complete (I followed them when I moved them from my programming computer to my server), these aren’t exactly polished for non-techie end-users at this point. However, I’ve been using them myself now for a couple of weeks and they work for me…

agaetr (GitHub, GitLab, my repo) is a modular system made up of several small programs designed to take input (particularly RSS feeds) and then share them to various social media outputs.

This system is designed for single user use, as API keys are required.

Tested with feeds from:

The preprocessing script is available (with examples) for fixing a few things with WordPress and TT-RSS "published articles" feeds.

agaetr can also deobfuscate incoming links and optionally shorten outgoing links.

This was created because pay services ( cough dlvr.it cough) are expensive, and other options are either limited or subject to frequent bitrot.

The modular structure is specifically designed so that it should be easy to create a new module for additional services, as it relies on other programs to do most of the posting. Therefore, if one posting tool dies, another can be found and (relatively) easily swapped in without changing your whole setup.

agaetr is an anglicization of ágætr, meaning "famous".

Special thanks to Alvin Alexander’s whose post got me on the right track.

orindi

orindi(Github, GitLab, my repository) transforms your e-mail newsletters into webpages and an RSS feed. Uses pico as a front end. orindi is an anglicization of ørindi, meaning "message".

The idea is that this should be able to slip into your existing workflow, regardless of what that is or what you’re using. And if it doesn’t, it’s meant to be as simple as possible to customize the code.

Why Pico and Procmail?

I’d previously used Kill The Newsletter which did a bangup job. But when the author changed it from using a cloud service to exim, I had a problem. I don’t use exim, and the configuration was in the code that I (quite frankly) don’t have the skill to understand.

Therefore, I wanted something that would rely on procmail, which can work with pretty much any mail transfer agent seamlessly, including after delivery if mail is in the maildir format. (See TODO if you’re about to say I should use something different like courier-maildrop.)

Pico provides a good front-end for similar reasons. It’s lightweight, does not require one to disrupt their existing setup, deals with plain text files, and can generate RSS feeds fairly easily.

Featured Photo by Sean Lim on Unsplash