Misfin meeting on IRC

Time: 18:00ish GMT on 2023-12-31

Venue: ##misfin on libera.chat

Participants:

• clseibold (Christian Lee Seibold)
• jmjl (Julián Marcos)
• mk270 (Martin Keegan)
• satchlj
• BBSman
• cipres
• jeang3nie

Overview

An informal discussion re the future of Misfin protocol, given the apparent absence of the originator ("Lem"). The meeting is without prejudice to any future governance arrangements for the protocol.

This doc will be updated as the meeting proceeds.

Content length

It was proposed, but definitely not yet accepted, to break backward compatibility by providing content length thus:

"misfin://@"

counterproposal:

18:33 <@clseibold> So, if we're breaking back-compat, and we want 
                   content-length to be optional, then I think your proposal is 
                   that we add a tab to tell the server that there's a 
                   content-length coming, and if there's not, then we could 
                   just use a space. So here's my tweaking of your proposal:
18:33 <@clseibold> With Content Length: 
misfin://@
18:33 <@clseibold> Without Content Length: 
                   misfin://@

19:39 <@mk270> (this can make the detection of end-of-message more reliable / easier to implement for those with weak TLS libraries)

resolved nem con: to go with the counterproposal of optional length

Max content length

proposed for 16K

Misfintext

(it is proposed to reword the spec to clarify how the header interacts with gemtext, without changing the semantics of misfin)

18:01 <@clseibold> So like, all we're really doing here is dividing the message 
                   body from the header format.
18:01 <@clseibold> To demonstrate:
18:01 <@clseibold> ---- misfintext header here ------
18:01 <@clseibold> > sender
18:01 <@clseibold> < receiver
18:01 <@clseibold> ---- gemtext body below here ----
18:01 <@clseibold> [gemtext body]
18:01 <@clseibold> Same format as what we currently have, we just divide and 
                   use different parsers for the two sections

(see below in next section for actual agreed proposal)

Inextensible metadata

was proposed by jmjl - how to implement?

ban commas from email address tags

exclude metadata from content length

20:28 <@clseibold> Here's my proposal for changing the misfin linetypes:
20:28 <@clseibold> address1 sender1_name, address2 sender2_name
20:28 <@clseibold> recipient_address1, recipient_address2
20:28 <@clseibold> timestamp1, timestamp2

• fields are: senders, recipients, timestamps
• omit the sigils (single char things at start of each line)
• we can omit the sigils because there will always be three lines, in a given order
• delimiter is ","; do not allow it in addresses/timestamps
• if a line has no content, it should be the empty line
• content length should not apply to this metadata (we need to be careful about whether the CRLF identifiers are to be included in the count)

A conversion tool can be provided for users of the old metadata format

Backwards compat

we should mandate that all new clients require the content length?

But all servers have to handle when there's no content length

yeah - the server is allowed to accept old metadata if the client sends no contentlength

but new clients must send contentlength

Message IDs

can be based on a hash of the senders, recipients and body, ignoring timestamps.

A server can calculate this. No need to change the wire format.

This is not going to be done immediately, but is for future ongoing discussion.

Known existing software

Clients

clseibold's misfinmail, reference implementation, cipres' fork, and gemalaya browser

Servers

clseibold's misfin-server, reference implementation, cipres' fork, miselfin, Dory, and I think there's a few other servers too.

Status

The original Lem spec is under a CC licence:

It was agreed that our document should include this by reference rather than inclusion, and be a "proposal" rather than any kind of usurpation.

The draft ID will be: e82fa2e9-a8e9-44f5-924c-77301643f5c2