yes, but with 50MB of monthly email quota and a slow connection, no one wants to send a big file using email anyway 
3 Likes
That is true.
he is not Cuban so he hasnāt that problems 
Let me re-frame the conversation based on what Iām hearing:
- Probably Delta.chat project would like to stick to email as a fundamental value to the vision of the project, which I understand and respect.
- At the same time, there are known limitations in terms of size and storage for most email providers that sooner of later can be a user experience issue for the app.
With that in mind: What would be the main characteristics that a file transmission system should have in order to align with the project vision? Once that is clear we might want to evaluate if there is already a solution that full-fit that or not.
Cheers.
1 Like
Some thoughts:
- every further external dependency makes DC more complicated.
- as adbenitez says: Sending large files is not a good idea in slow networks.
- How stable is a direct p2p connection? I think sending reasonable file junks by mail could be the more stable solution.
- splitting files for sending them by email is commonly used with standard MUA and there is not really a problem when using this approach if servers have the space and bandwith.
I think the way to split files to several mails is the easiest approach because all technology is existing in DC.
A first approach could work without sync mechanism. This would at least serve for people with big enough space at server.
ā¦ and is usable by standard MUA too in a manual way!
8 Likes
This issue is not very important? 
It is required an internet connection to use the ipfs network.
People in Cuba pay for mail only and using intranet a big part of the time. Internet connection is expensive in comparison with the intranet.
Pydio?
DO Spaces?
Upload multiple files with simple drag-and-drop and manage all your content from a beautifully simple control panel.
Respect your recipientās email storage and isp bandwidth
2 Likes
Want to recall comment from Jun '19
splitting large files sounds great i love to see that
for those who are concerned about storage space on servers you can still add a limit (for example 70mb) which is the same as sending something like 20 photos.
yes but it is possible to add a limit (50-80 MB) for split-able files
it will be like sending 2 25MB files
user-group use it onprem imap server and very big file size supported, but dc static size using 25MB.
I think ipfs could be the way to go instead. As they suggest in their forum, IPFS for file distribution in local network - #5 by wclayf - Help - discuss.ipfs.io but also Ipfs only in a local network - #9 by Kubuxu - Help - discuss.ipfs.io (these are the first two results i got from googling āipfs local networkā) ipfs can be hosted on a āprivateā network. So, in other terms, if youāre in a country with a restricted connectivity or with a particular internet setup (as in this case Cuba) you can use that one instead of the public mainnet. It would be only a matter of adding a specific setting in the Delta chat application regarding where to share a file.
In my opinion this would fit the decentralized nature of Delta chat, giving the possibility to choose where you want to share your file (in which ipfs network).
A solution should (when ever possible):
- not adding any further external dependencies
- working everywhere
- reliable
- simple to implement
I would see these traits in āsplit fileā approach.
4 Likes
that is correct but as a messenger app one may send 2 videos(25MB+25MB) per day and its the same thing as sending one large video(50MB) so we are doing it right now.
i know i mentioned this and i donāt want to be annoying but its a very big improvement and all my friends are waiting for this to happen.
Isnāt it that with this system there is the problem of quickly consuming the daily limit of emails? 
2 Likes
sending a large file will create this problem.
by adding a limit for split-able files lets say ~50-70MB the number of parts are reduced so one 50MB video will be sent as 3 or 4 emailsā¦thatās not a lot
right now the file size limit is too low.
BTW: Regardless of the size of the attachment, it is up to the recipient to decide whether to receive the attachment. The current version always forces the automatic download of the attachment. To improve this, please refer to Telegram.
2 Likes
At least for DC to DC transfer there could be the possibility to send an opening message with a ātransfer big dataā request. When receiver confirms, then the real transfer in multiple bigger chunks could start.
I suspect for a standard MUA this is not possible (or only manually).
2 Likes