add misfin

This commit is contained in:
Satya Johnson 2023-05-07 01:01:02 +00:00
parent e92b5ab20b
commit e4d3504822
1 changed files with 45 additions and 0 deletions

View File

@ -0,0 +1,45 @@
# Thoughts on Misfin
2023-05-06
Over the past few days, lem has been over at misfin.org making the new internet mail spec a reality. Yesterday, I sent the first misfin message. I want to jot down a few notes for reference as things move forward.
=> gemini://misfin.org Misfin
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.
## 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.
=> gemini://misfin.org/specification.gmi Misfin spec
=> gemini://tilde.team/~satchlj/message.gmi Example message
### 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.