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
`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!
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.
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.