💾 Archived View for gemini.ucant.org › heterodox-tech › misfin.gmi captured on 2024-06-16 at 12:02:30. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Misfin: a smallnet messaging protocol

Misfin is a lightweight messaging protocol, similar to SMTP or WhatsApp. It uses mandatory TLS and the Gemini text format.

There is an active proposal for a new version of misfin, called misfin(C). The original developer of Misfin has recently come back into contact. The best place to talk about implementing misfin is the ##misfin channel on libera.chat

I am committed to keeping this page up-to-date, accurate and comprehensive. Please contact me with any corrections.

Misfin(A), Misfin(B), Proposed Misfin(C)

Misfin(A) and Misfin(B) are two version of Misfin, created by Lem, the originator of Misfin.

There is a community proposal for Misfin(C), negotiated between implementers via IRC. This is still in draft form. Misfin(C) is deliberately incompatible with Misfin(B). This means that conformant Misfin(B) servers will continue to enforce Misfin(B)'s stricter message length limits.

Misfin(C) is in no sense endorsed by Lem, the Misfin maintainer.

Agenda

My own agenda re Misfin is:

improve Misfin implementation testing
assess and document Misfin implementation interoperability/conformance

I expect the first three stages, which are in progress, to take until early Feb 2024.

Current focus

deploy infrastructure to allow third parties to test Misfin servers
get good example misfin(c) requests/responses written up

this section last updated: 2024-01-30

Implementations

Clients

reference implementation

cipres' fork

and gemalaya browser

clseibold's misfinmail

Servers

reference implementation

clseibold's misfin-server

cipres' fork

miselfin (no full public source repo yet)

Dory

Issues

(This list isn't necessarily up-to-date)

messages aren't encrypted at rest / intermediaries can intercept the messages, even though sender likely has the public key for the recipient
mailing lists: only the last hop can be verified
implicit ambiguity re CRLF/LF in the lines part of the misfin(B) spec
TLS libraries are a bit shaky on self-signed certificates, the proffering of non-mandatory certificates, etc
TLS libraries use different ASN1 data types for representing mandatory fields (like subject alt name) required by misfin
the misfin(B) spec could be portrayed as trying to extend Gemtext format
in principle the misfin(B) metadata lines could appear anywhere in the body of the message
there is no obvious way that the holder of a mailbox can attest that the server is authorised to receive messages to that mailbox over misfin
the spec should be explicit about which metadata, if any, should be sent by initiators of mesages
it should be explicit in Misfin(C) that the receiving servers adds the sender and timestamp, not the sender
what support should there be for null-body verification messages

What Misfin is not

Misfin is *not* a protocol for retrieving or manipulating messages stored on a remote server, on behalf of one or multiple clients
Misfin is *not* end-to-end encrypted in the accepted sense of that term, but it *is* mandatorily encrypted and thus protected against middleboxes

There are related protocols for dealing with these two issues:

GMAP

LATSSIAM

Misfin: a smallnet messaging protocol

Misfin(A), Misfin(B), Proposed Misfin(C)

Agenda

Links

Misfin(C)