PhilI had been thinking about the filtering part of #fcli, my #Mastodon to #email bridge as 'similar to #procmail', but today I realised that if I add custom headers to the email messages it produces I can just use procmail itself. By interfacing #Fediverse ideas with email standards I seem to be needing less and less custom code to get a setup which works for me, and making more and more use of decades old open source software, which is actually a pretty great outcome.
I'm thinking about experimenting with replacing the filters in #FCLI with something more general purpose, inspired by #procmail recipes.
Procmail uses regular expressions on email headers (and bodies), so I wonder what the equivalent is for #JSON documents. Is this an #XPath like use case? I started looking for the JSON equivalent of XPath, and found #JSONPath, and then realised that XPath supports JSON natively nowadays.
The presentation needs to be improved a bit, but we now have #Fediverse posts in #mutt complete with attachments and other links, with descriptions, as an attached #linkset. This is using #fcli, which is my #Mastodon to #maildir / #SMTP bridge.
The main problem is that the linkset viewer is a bit slow - it probably needs to become a simple C application rather than part of the Python monolith.
I also need to implement support for posting with attachments in the SMTP side of the bridge.
The other thing I've been doing is getting up to speed with #RDF, #FOAF and other #semanticweb technologies. I'm trying to build a representation of my social graph which I can query using open technologies, and converting what I can download from my home instance via the #mastodon API to FOAF was pretty straightforward, although I haven't yet really tried querying it yet, which I'm guessing either means learning #SPARQL or finding some sort of graphical explorer app.
I think there are two directions in which I want to take this. First is analysing the post history, e.g. looking at the #tags people use. Because of the way #FCLI works I've built up an archive of around 300k posts ready to do that with, so there should be some interesting data there.
Secondly, I was thinking about following the social graph to higher order connections, i.e. who the people I follow follow ...
2/n
#Fediverse projects this week. Firstly the easy one - I've added some basic support for (receiving) attachments in #FCLI, which is my #Mastodon to #maildir bridge to allow me to interact with the Fediverse in #mutt.
Currently it's just a list of URLs and descriptions at the end of each post. I was planning to present them as #MIME attachments, but that model doesn't really work - I don't want to download everything just in case, and I don't think there's a standard way in email to present an attachment as a URL to download on demand. At some point I may experiment with a new MIME type and custom handler to do that, but I think I'd still want the descriptions in the main message anyway.
I should also add that the thoughtful Fediverse norm of adding #alttext makes this so much easier, so please keep doing it. #accessibility opens the door for people who couldn't otherwise interact at all, and that's the most important bit, but it makes life a little bit (or a lot) easier for the rest of us too.
1/n
I've written up some notes on recent #fcli work here:
https://philcowans.com/articles/2025-11-03-fcli-update.html
This is my experiment bridging the #Fediverse into standard email infrastructure, so I can use #mutt as a client. So far it's working pretty well, and I plan to keep working on it.
I've uploaded my recent changes to #fcli to the origin repo:
https://github.com/philcowans/fcli
This is my personal project which is becoming a set of MTA / MDA tools for bridging the #Fediverse into the email universe so I can use #mutt as my client. It's roughly along the lines of #fetchmail, #sendmail, #promail, etc. Currently it's a bit of an unholy mess as it transitions from being a stand-alone client to a piece of plumbing, and the new stuff is completely undocumented. I'll update the documentation and write a blog post covering the state of play later, but let me know if you want any more info before then.
At some point soon I'm also planning to migrate hosting away from GitHub, but I'll stick with it for the time being so I have somewhere to share the most recent version of the code.
