💾 Archived View for bbs.geminispace.org › u › jeang3nie › 2791 captured on 2023-11-14 at 10:42:21. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-11-04)
-=-=-=-=-=-=-
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.
Jul 04 · 4 months ago
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?
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)
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...
🦀 jeang3nie · Jul 10 at 23:17:
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.
@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.
@lem I would love to hear your thoughts on this.
🦀 jeang3nie · Jul 12 at 16:20:
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.
🚀 clseibold · Sep 25 at 04:56:
This limit talk doesn't make sense. People can already send an infinite amount of data by just making their own client that doesn't follow the spec. The limit or non-limit, then, becomes the burden of the receiving end - there's types of attacks where you send large amounts of data to a server. The solution to this is to just close a connection after having gotten a certain amount of data. You have to have a limt for this anyways, no matter what the spec says. It should just be high, like 500 KB high.
There's legitimately no other reason to have such a low limit than to try to mimick Gemini. But there's no reason to mimick Gemini here. Design your protocols for their purpose.
I seen it mentioned that Gemini is just fine with 1024. Yeah, sure, because you don't write private emails in Gemini, *and* Gemini servers are better able to manage connecting two inputs up together. This protocol doesn't have any mechanism to append to the last-sent message.
Gemini is focused on *downloading* content, email is focused on what is basically *uploading* content. They're two different things. 1024 and 2048 characters are not enough.
And this is not even getting into the fact that 2048 bytes isn't even 2048 characters for any language that doesn't use the Latin alphabet, lmao. You'd be halving (or more!) the space for speakers of Arabic, Hebrew, Persian, Japanese, Chinese, Korean, and a bunch of other languages. For Hebrew, you'd only be able to type 1024 characters in 2048 bytes.
Interestingly, this send directly to the server type of email system is not totally dissimilar to Titan. The benefit of mimicking email's current decentralized system is you can send an email even when the destination email server is down - however, this isn't really all that necessary, at least anymore.
Lastly, I *frequently* write more than 2048 bytes in an email.
Edit: For the idea of breaking messages up - you also have to think about how this is going to interface with the user on the receiving end. I don't want to have to sift through a bunch of broken up emails! People already miss back-to-back replies in traditional email, so why would we want to make it even worse?
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....