💾 Archived View for bbs.geminispace.org › u › clseibold › 5521 captured on 2023-12-28 at 18:13:41. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2023-11-14)

🚧 View Differences

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

Comment by 🚀 clseibold

Re: "Message Size"

In: s/misfin

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?

🚀 clseibold

Sep 25 · 3 months ago

Original Post

🌒 s/misfin

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....

💬 ERnsTL · 14 comments · 2 likes · Jul 04 · 6 months ago