Surprising Uses of Email
zanneth.com
zanneth.com
One usecase I was thinking about: when subscribing to a mailing list, by design you don't have access to the archives, you will only receive new emails. Archives are to be browsed in another tool, with another protocol. What if we turned the thing on its head and get closer to NNTP: when a user is interested in a mailing list, they IMAP-subscribe to a specific folder (/lists/announce@myproject.org) and the server will IMAP-subscribe to upstream. Auth is managed automatically, no need to send an email and verify it. Archives are naturally handled. A smart server would provide dynamic listing of content without having to download evertyhing, so that browsing old posts can be efficient.
Some other unorthodox uses of email:
- deltachat (https://delta.chat/en/) replaces whatsapp: it's an instant messenger with e2ee based on autocrypt (https://autocrypt.org/)
- RMS used email to fetch webpages he wishes to consult (https://lwn.net/Articles/262570/). Not sure it is still true today.
> The RSS to email thing is surprisingly good
RSS is a great example. I just filter them into folders and read them when I have time. I never miss a post. Futhermore it is synced across all of my devices and available offline (although I wish I could find an email click that would pre-download images for selected folders/labels).
> I'm currently looking to put the same thing in place for a read-it-later usecase
I would use this. An easy button to send an article to my email (automatically filtered into a folder of course) would be fantastic.
> when subscribing to a mailing list, by design you don't have access to the archives, you will only receive new emails
I think this is the biggest failing of email. Of course for some use cases this makes sense but there are cases where you mentioned where it would be amazing. Even when forwarding messages to friends it would be amazing if I could also give them access to fetch the referenced messages from me. If people are just mass quoting the whole message it kinda works (but is really bad UX) but natively seeing the whole thread would be amazing. Same problem with mailing lists when you subscribe and start getting replies to mesasges you haven't received yet.
It would be interesting to apply some IPFS to email. Imagine replacing message IDs with IPFS CIDs of the encrypted content. Then when you forward a message you could reference CID+key to share the messages with the receiver. (There are a lot of details to work out but it seems like an interesting idea)
(I use https://blogtrottr.com/ and am very happy but self-hosted options are easy to set up)
Another use case I would like to replace with email is push-notifications. Most notifications I get on my phone aren't device specific and it would be great if I could get them via email on all of my devices. This gives a huge amount of features that aren't available in the (pretty basic) notifications feature on phones.
- Cross-devcie - Archived (if I wish) - Snooze/filtering/organization - Customizing notification policies (phones do have some form of this) - Easy forwarding if desired.
I think the only thing that I would miss is the apps can dismiss notifications that are no longer relevant.
Of course email is probably not the optimal protocol for this. But everyone has it and it works well. Something like Matrix is probably better however I don't find that the "room" organization is optimal for everything. Email could probably use something like that (mailing lists seem like a slightly hacky solution) but I also like that email is based around "send me a message, I'll figure out how to organize it" whereas Matrix and other IM systems make the sender do the organization and to a large degree everyone in the network needs to respect that.
That's something I was thinking about a lot a few years ago.
I think this could work with a tiny email extension: If the email would include 2 extra header called e.g. "X-Revisable-by-public-key: <public key here>" and "X-Revision-signature: <signed sha512/256 hash of message>"; Then, a future message with the same message ID (or perhaps X-Revises-Message-ID:...) properly signed, would replace a previous message in the notification UI - perhaps giving an indication/view of the previous revisions.
A mail client that does not support this header would simply not dismiss the no-longer relevant notifications but would still be fully compatible/capable, and the "message read" among different clients would still operate properly.
The main thing that makes me cringe about using email for everything, e.g. things like delta.chat, is that I accidentally do "view source" on one-body-line messages: The modern overhead hurts my engineering sensibilities. Seems like Google easily adds 3K of envelope and metadata to a 120 character email. Acceptable as transport for a 3MB email with attachment; Unacceptable for a 6-char "ok lol" delta.chat message.
If you set up a Mail server that uses sieve, I wrote a tool just for this. I use it all the time for read later, all you need to do is send an email to yourself with the URL in the body and my sieve script downloads the page, formats it, and files it into a specific mailbox.