Thoughts on Misfin
Over the past few days, lem has been over at misfin.org on gemini making the new internet mail protocol a reality. Yesterday, I sent the first misfin message as mail@satch.xyz. I want to jot down a few notes for reference as things move forward.
First, why use Misfin? What's wrong with regular old email?
- Email supports tracking
- It's next to impossible to self host email usefully, due to complexity, spam, and the immense difficulty of getting delivered to providers like Gmail
- Email allows for easy spoofing
In my opinion, the central advantage of Misfin is that, compared to email, it is incredibly easy to self host due to its simplicity. Here's the git repo. You can get this running in minutes on a VPS with an up-to-date python installation.
Thoughts on the spec
On May 6, lem added a section on the mail file format to the spec. There are two notes I have about it which I feel are important.
Longform Addresses
In section 3.1, the spec says:
A Misfin address is written as "mailbox@hostname", or "blurb (mailbox@hostname)" in longform.
In section 4.1, the spec describes the sender line:
The sender line records the Misfin address of the user that sent the message. Sender lines begin with a single "<" character, and have this syntax:
< mailbox@hostname.com blurb
While these parts of the spec are not contradictory, especially as the intended use of the longform in section 3.1 is not made explicit, I feel that they introduce confusion by giving two different ways to list the sender. However, I understand the advantages of both in their respective contexts: the first is easy for a human to read, and the second is easy for a client to parse.
Timestamps
In the second line of section 4, the Misfin spec says:
Misfin clients and servers are welcome to store any other message information (e.g. timestamps), but must not do so in the message itself.
While I agree that including timestamps in the message should not be required by the spec, I do not agree that it should be forbidden. I believe there are cases when it is useful to have this information in the message itself, primarily for forwarding purposes.