When the size of the attachment exceeds a certain value set by the user (for example, greater than 18 MB), it is uploaded to a cloud storage instead of directly transmitted in the email. After the upload is completed, a message is sent to the other party. The original message describes the basic information of the file. It can be a json. Like this:
Delta Chat needs to wrap json to make it easier to read in conversations, similar to Telegram.
If I am the recipient, this method allows me to choose whether to download or not, to avoid being forced to consume data traffic to download some unwanted things. Because all attachments in the current version are unconditionally downloaded automatically.
Disclaimer: The above is just an assumption, maybe there is no such a cloud storage interface for granted in the world.
i kindly but strongly disagree. DC’s great fundamental feature is that its transport layer is Email. To weave an other transport system into it is against its base ideas, IMO.
which cloud storage? people have widely different preferences on it.
how would it integrate smoothly to other email softwares?
how are recipients authenticated at that particular cloud provider?
(there is no cloud, just someone else’s computer.)
how non-DC recipients keep the attachments as easily as real email attachments?
how long keep the file in the “cloud”; what if the recipient does not open the link immediately? (remember, email is not meant to be instant)
with detached attachments (see the oxymoron) many DC killing feature get impacted.
as I expressed in an other thread (Smarter message size limit), an SMTP protocol extension would be the most elegant to detect max mesage size. And to “push everything through”, send huge files in chunks automatically (DC should split and concat them without user intervention).
I agree not to force users to download large messages unconditionally.
IMAPv4 supports downloading only the headers, or the message partially IIRC; so downloading whole huge attachments unsolicitedly has not to be an issue – it can be implemented in DC without ecosystem change.
Sending as link is probably better in current situation of email ecosystem, attachment size is pretty limited, message sent are rate-limited, some part could just never arrive, and using an HTTP server to upload attachments is pretty much the same that is done in the XMPP world. In practice when someone send big files via email what they do is to upload it somewhere and share the download link, it is too much work for someone using a normal email client to download several parts.
First of all for medium sized message that can still be sent via email (attachment size under the limits of most providers.
The problem here is that for most people on mobile there is still a data limit on how much data they can transfer in a month, so the current behavior of downloading everything immediately isn’t ideal - see related topic for more details on this: Addition of automatic media download feature
Then for really large files the idea is to use another transport than email:
simple fileservers, could be configurable like videochat server currently is and also providers could provide this as extra feature to their users in the future, there is already a prototype pr exploring that idea, but its inactive right now [WIP] Upload and download large attachements through HTTP by Frando · Pull Request #1612 · deltachat/deltachat-core-rust
in essence it would be a specification that declares an interface where files can be uploaded and then returning a link from which they can be downloaded again. which is just an automated mechanism of sending a link to the file.
using a p2p transport (device to device) but that has the disadvantage that both devices need to be online at the same time for the duration of the transfer, also special software if not using deltachat is required to download the files. (unless all other mail clients implement that spec too)
Sending the download link directly is of course possible, but this is not elegant enough. Because to send a large file, I need:
Upload to cloud storage;
Manually obtain the download link of the file;
Go back to Delta Chat and send the link to the other party.
At this time, the other party may encounter:
a) The webpage pointed to by the download link cannot be opened;
b) The file is censored and blocked;
c) Poor connection or limited download speed;
d) The other party is a computer/mobile phone idiot or other circumstances that make it impossible to download files.
My assumption is based on the fact that I have a NAS, in addition to building a mail server on it, I can also build a file sharing mechanism “specially used for Delta Chat” on it (if this mechanism exists, the space and file validity period are not considered for the time being). The specific implementation can set an API address like video chat.
When this mechanism is highly integrated with Delta Chat, sending large files will no longer be painful.
Curently Delta Chat has support for video-chat conferences invitation and that has nothing to do with email, it simply can’t be done in any sane way via email, we must accept email can’t cover all needs and having a solution that works and integrates nicely is better than nothing, or something that will virtually not work, like sending a ton of parts, there is not only the size limit in the sender side but in the receiver side, then think about groups where everyone can have different limits, even if you can send up to 50MB with your email server, the receiver’s email box may only allow up to 2MB for example, so your bunch of messages will never arrive, then even if it arrives, your peers may have a box size limit, for example in the case of nauta.cu the inbox is only 100MB per user, so users will be pretty annoyed if you fill their inboxes and then they lose incoming email because their INBOX was full.
Also currently users are not aware in Delta Chat when their inbox is full, so they will be confused and just think that Delta Chat stopped working.
this also depends in the situations, if you and your friends are self-hosting for example with yggmail, then sending big emails or a lot of parts is not an issue at all
I currently use poste.io, which runs in Docker.
I did not strictly limit the size of the attachment (currently 200 MB), which means that the size of the attachment that can be sent at this time depends entirely on Delta Chat (the maximum size that can be sent by the DC prompt is 18 MB, but I have tested it many times and found that it can be sent The maximum size is about 36.5 MB. When trying to send a 36 MB file, the client will have no response for 10-20 seconds).
