@hpk, I think this would be better for people on Cuba or other countries with an only-email connection.
Is email space quota free??
Better ask @adbenitez about that.
Also remember in box size… even when you’re deleting the file on the emailserver as soon as you downloaded it - what happens when you are off-line while people send you stuff?
Right: the inbox gets full and you can’t recieve any messages anymore.
I think keeping that in mind, it makes sense to do the “handshake”/matchmaking over email and let the file transfer be done in a different protocol/by different means.
Verification system: No new part is send until the old part is confirmed to be received (and deleted), this would work with read receipts system already implemented but making it mandatory.
Ah… that sounds too complicated, and if both are online anyway you can establish a direct p2p connection and transfer the file that way.
“Keep it simple and stupid”
Privacy, if not I would say “torrent”. And yeah is too complicated but not for me because I am not a programmer jajajajajajaja.
Then establish a p2p connection through tor
For a joke is great, but there are several reasons because torrent over tor is not a good idea. The main reason is overflow the network.
https://blog.torproject.org/bittorrent-over-tor-isnt-good-idea this for others
p2p !== torrent
I mean the p2p where you download directly from your chat partner.
I know, and I repeat again:
Torrent has a verification system even to look for errors in parts and you can broke a connection and continue several days later.
I think dat would have similarities to torrent…
But anyways my Point was about why I think file sharing over email isn’t a very good idea.
Like e-mail is made for Letters but we need “E-Shipping” for big data-packages…
Does something like that exist? Something similar to email but for larger files?
I dont know, I was only proposing the idea to reduce a possible (in a future) dependency in external services (also exists lufi, used on https://upload.disroot.org as a replacement to Send). It is possible over e-mail why not try it?. Anyways, I began proposing this because @adbenitez told me there are (also) contracts only for email connection and not general internet in his country.
Oh, I just remembered some bad experiences over people who live in very far countries or locations (venezuela, chile and the main land of spain) when I was trying to send a file over torrent 100 kb/s of upload from my router and ~200kb/s of download of a friend and a final transfer rate of 4 kb/s (venezuela case) and with calls using SIP in p2p mode (to all that locations and using Linphone [no problem to near people and using the server except a year ago using the flexisip server from the Linphone]) with the lowest bitrate and quality audio codec and trying to maintain unstable calls.
I also tested tox, if I remember, with similar problems.
I thought on problems with high latency.
yes, but with 50MB of monthly email quota and a slow connection, no one wants to send a big file using email anyway
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.
- 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!
This issue is not very important?
https://ipfs.io/ should fit the bill.
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.