💾 Archived View for bbs.geminispace.org › u › alexlehm › 2869 captured on 2023-09-08 at 18:23:04. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-07-22)
-=-=-=-=-=-=-
i think the author says that larger messages could be put on an url and the url could be in the message (to replace attachments)
2023-07-06 · 2 months ago
@johan Good point regarding the headers! Didnt think of these - they also cut down the net remaining message size...
2023-07-10 · 2 months ago
There really aren't headers in Misfin per se. There's the recipient's address, a space, abs then the message.
That said, if forwarding a message, there could be an extra timestamp line, along with extra sender lines. And a mailing list could eat the entire character limit with a really long list of recipients.
To be perfectly honest, I'm in favor of not having a limit _at all_ for such reasons. It's problematic. A message can be fully compliant, but not forwardable due to the limit. And the mailing list is case makes the limit very problematic. So while a lot of you have argued for a 4k limit, I say no limit is probably better.
Putting it in perspective, the maximum path length on Linux is 4k.
If the spec were to be amended to have no limit, however, I'd also like to see the sender send the message length before the message so that the server knows that it has got the entire thing. That makes server design a lot easier.
Generally speaking, Gemini has shown that even a 1024 byte limit is workable, although cumbersome. You can always send a sequence of multiple messages if the content is too long to fit into one.
Personally I would like to see _a_ limit, because it makes implementation a bit easier since one doesn't have to be able to receive unlimited lengths of incoming data, and there is no need to include a content size header.
2023-07-11 · 2 months ago
@jeang3nie no time to give my flushed out thoughts, but some limit is absolutely essential unless we are talking about misfin a, which was already kinda rejected in favor of misfin b.
However, I agree that mailing lists and similar things become very problematic in the presence of limits because perfectly compliant messages can be unforwardable. I don’t know what the solution is, but maybe misfin A is the way to go.
2023-07-12 · 8 weeks ago
@lem I would love to hear your thoughts on this.
I'm not so tied to the idea of ditching the message length entirely that I'd be upset if it was kept. I think it should be what the community wants it to be. 4k would give some breathing room, and might inpractice solve the issues I pointed out, even if it's still theoretically possible to hit the limit when you try to forward a message.
I can see a few possible solutions to the long recipients lines for mailing lists, and extra senders lines for forwarded messages. One solution for the former is for mailing lists to simply forgo the recipients line altogether. When you reply to the list you should be replying directly to the mailbox associated with the list anyway, so a long list of the other folks who have also received the message is basically just noise.
As for the latter, the mailer could automatically break messages if they go over the limit, eg when forwarding and an extra sender line gets appended.
Either way, I still don't particularly care for the current size limit. I'd be happiest with no limit, and still pretty happy with 4k.
Message Size — How did this limitation of 2048 bytes happen? I am personally not sold on this size; I have generated some lorem ipsum text and even without characters using 2 or even 3 bytes... emoticons and accent letters or complex letters (Asia, India etc.) ... the 2048 bytes are about two or three longer paragraphs. If the point of Misfin is to gain wider traction, maybe look at 4096 bytes? Then there would be a big counter-argument less, and I presume acceptance would be better....