Extended attributes

IMVHO, extended file-attributes (AKA: xattrs) are incredibly cool and incredibly useful! I lament the current state of the Free Desktop landscape (BSDs/LiGNUx, etc.) in regards to extended attributes: They're second-class citizens, rarely used or supported. Forgotten.

I used Haiku as my main operating system for a couple years, and it revealed unto to me the beauty and sheer power of extended attributes. Haiku uses them extensively, whether in the file-manager, programs’ backends as the backing of a database, or in file-types generally: Contact-file? Empty file with xattrs for metadata, more like. E-mail? Empty file with xattrs for metadata, more like. Enlightenment? Love? Found on a T1 line.

I’d like to use xattrs wherever they seem useful, to bring Free Desktops in-line with Haiku — and by extension, the future. Extended attributes, spread far and wide! :D

To this end, I wrote the xattr library for Chicken Scheme, and made an RSS/Atom program that uses them as well, feedsnake. However, I’ve since started using another program for this, sfeed.

chatd

`chatd` is the name a little project of mine with the goal of a general and protocol-neutral interface for chat programs, á la Pidgin and the sort. Here's my dream: One could write a simple chat client that can grok the `chatd`-format, and so can indirectly support several protocols (XMPP, IRC, Matrix); and one should be able to write for such protocols a simple client daemon that would ouput info in the `chatd` format.

Server → Daemon → Client

Ideally, this sort of setup would enable: Easy scripting for the user; equal interfaces between protocols; cohesiveness; simple and well-modularized code; neutrality of language (a client could be in, i.e., Python, and the client daemon could be, i.e., Ruby). Right now, the structure I'm going for is JSON as the format used between client and daemon. Output of the daemons should be to a simple text-file, and input should be from a FIFO file, similarly to ii. To that end, I've already begun to write a client-daemon for IRC, irc-chatd, an IRC library for Chicken Scheme ircc, and a client-program in the style of `ii`, “kittd.”

At this early stage of the project, I'm still exploring other similar efforts. At the moment, Telepathy has caught my interest. From a brief glance, it seems like a nice protocol; supposedly, D-Bus (which it requires) is somewhat bad, but I don't have a strong opinion there. Maybe I'll scratch my efforts until now and become a shill for Telepathy!

Data-hoarding

The ability to export a service's or program's data in a parsiblity format is vital. For example, it should inherently be simple to export messages to plaintext (or at least HTML!). It's easier to search through files directl, and you really can't trust that the server will retain whatever logs/data you like. With XMPP/Matrix E2E, for instance, it's fairly common to lose your encryption keys, a crime punished with a total loss of chat-logs. Because of that, I work on scripts for backing up such data, from time-to-time: dino-chat-export, divercities_dl, wyrics, etc.

E-mail

With the Haiku operating system, e-mail messages are just a sort of file, with extended attributes containing metadata of the message. Haiku's file-manager, Tracker, was made with first-class support for extended attributes, allowing it to display e-mail as well—or better—than any e-mail client. And Haiku's e-mail reader? It's simple and fabulous.

I'd like to Haiku-ize e-mail management on LiGNUx, and to such an end I've worked on two projects: nautilus-maildir and Mailduck. Mailduck is a simple QT-based e-mail-view, but is a work-in-progress (multi-body messages are not well-supported). And nautilus-maildir is an add-on for the file-managers Nautilus/Caja/Nemo, which displays e-mail file's metadata in columns, similar to Tracker.

Haiku-ing

As previously mentioned, I kept busy for a while with Haiku's community and software ecosystem. It's a system so beautiful, so simple, so progressive yet unique (both aesthetically and technically), that its allure is irresistable. TL;DR, heck LiGNUx, death to BSD, and Plan 9 can pound sand. Viva Haiku!

I wrote several programs and scripts for Haiku: Chat-O-Matic, Pogger, MediaMonitor, et cetera. My other main contributions were to Calendar and TrackGit. The most weighty work was probably on Chat-O-Matic, which was my 2021 Google Summer of Code project.

… but, sadly, I yearned to return to the “real world,” where LiGNUx is the only competitor with Windows and macOS, a place where even Firefox can be executed. There are many small things I miss from Haiku, but what truly bothers me is the lack of cohesiveness, slapshot support for extended attributes, and the lack of a truly pleasant file-manager. That last one really bugs me.

coinsh.red

Before Raddle (Reddit-like board) supported image-uploads, there wasn't really any fitting image-host for the community. The choices we knew of either required too much JavaScript, didn't respect privacy, or were hosted by “fascists.” So, I made my own over a weekend: That was insert-coin, the first version of coinsh.red. It was (IIRC) my first PHP project. It wasn't pretty, but it worked.

I worked on that for a while, until I ran into IPFS, a distributed network that hopes to supercede HTTP(S). I then made a new version of the site with Common Lisp, which uploaded each file to the IPFS network: cl-ipfs-api².

At some point, Raddle enabled image-uploading, and I started to tire of caring for an IPFS node; so I disabled file uploads. Overall, coinsh.red has hosted 93GB of files over 18835 URL redirects.

LibertyBSD

LibertyBSD was a project to purify OpenBSD into a fully-free and FSDG-compliant BSD. It was founded by Riley Baird, who published the first couple of versions. When he was unable to continue hosting the website, I took over as host. After Baird left the project, I started to work on new versions with Einhard Lᴇɪᴄʜᴛꜰᴜß, Jimmybot, and alimiracle, and a couple other contributors.

After some releases, it was found that some vital files lacked license headers, and were therefore considered proprietary as per the GNU project's standards; although this was considered a non-issue by the OpenBSD project. I lacked the skill and time to replace these files myself (by a long-shot!), and so I archived the project. It was a poor effort, but it was an effort.

A much better effect is being undertaken at this very moment by the folks of the HyperbolaBSD project, who are trying to make a fully-free BSD system using the OpenBSD kernel. This includes, of course, replacing the aforementioned licenseless files.