💾 Archived View for bbs.geminispace.org › s › misfin › 1834 captured on 2023-07-22 at 17:08:48. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-07-10)
-=-=-=-=-=-=-
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...
... 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.
Just my thoughts... what do y'all think?
2023-07-04 · 3 weeks ago · 👍 norayr
I'm actually with you on this. I don't see a reason for keeping messages this small. I realize that you can fit a lot into 2048 bytes, but to me the small web isn't about size so much as reduced complexity and the person to person aspect.
It's probably arbitrary.
Same here. I think @lem’s thought was “just send two messages.” What’s missing is a solid justification for the extremely short length. A maximum size is necessary, but 4096 bytes is still very small to a computer while much more comfortable for humans.
One good thing implementation wise is that I'm pretty sure it's a single line change in Dory to go from 2048 to 4096, if that's the way that people want to go. That said, it would be great to nail the spec down sooner than later.
I think 4096B makes more sense too. Especially since headers are expected to be included when forwarding or replying we could potentially lose some to overhead there. btw would those headers be repeated if we send multiple messages to cover a long reply?
2023-07-05 · 2 weeks ago
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 weeks ago
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)
@johan Good point regarding the headers! Didnt think of these - they also cut down the net remaining message size...
2023-07-10 · 12 days 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 · 12 days 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 · 11 days 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.
2023-07-12 · 10 days ago