logoalt Hacker News

gorgoiler • today at 7:04 AM • 0 replies • view on HN

“Email client” is an interesting puzzle. Email involves multiple activities:

Viewing: I have a message or messages stored on disk in files or mboxes or a maildir. How do I render them? Example use case is evidence in a law suit or, more likely, emails I’ve put in a shared drive to help me and my partner argue with our landlord. Yes, I could just have a Gmail folder for these but I don’t want to have one foot in a file-filesystem and one in a mail-filesystem. I want “lease_2024.pdf” and “20240401_deposit_confirmation_002.eml” to both be files. But then of course we have…

Filesystem interface: Emails have important attachments with MIME file names. Or perhaps a more keen observation is that some named files have emails as attachments! I’d like to symlink into a virtual FS that keys files off a UUID / Message-ID, and be able to mount that virtual FS from any mail store I have available (Gmail API, JMAP, IMAP, .tar archive, mbox, maildir, or .eml files.) Most conversations I have with people don’t involve files, and most files don’t involve conversations, but when they do I want them to feel natural and not some kind of special category of filey-messagey thing that doesn’t play well with plain files or, less commonly, plain messages.

Composition and sending: Creating a new message involves making a new file and then using that file to drive a sending API. I want to compose a beautiful email using a tool that is good at that job. Maybe I’m using vim to draft it in markdown with macros and tools to machine build certain complex parts? I also need some mime aware tooling — sometimes — to help prepare a bunch of attachments that may or may not have names related to their names on disk! I want all of this to be scriptable, on the occasions when it’s complex (30 part message for a client’s loan application!) and easy when it’s ad hoc (to: mom, see cat.jpg).

Search: email is notoriously the extension of and replacement for my long term memory. I have gathered message history from many sources and accounts over the years. I need to manage these into packed archives for the old ones, editable archives for the current ones, promote the former to the latter, and arrange new messages into the system. This feels like another separate tool.

I’m sure there are other potential tools lurking here as well. Separate rendering, composition, sending, receiving, searching, and archiving, feels like the goal. Most new email apps I see try to implement all of the above in one new package when, really, it would be great to see innovation on each branch of email as separate tools.

My PDF viewer doesn’t need to innovate on file browsing! My SVG drawing tool doesn’t need to innovate on mounting remote filesystems via SSH!