> 10GB is pretty much nothing nowadays, and once one has downloaded it then one only has to download the updates, not the whole thing from scratch. And local search is so much faster than remote search that it is incredible. Using notmuch for email is such an improvement over the Gmail web UI; it really has to be seen to be believed.
10GB is more space than a very significant fraction of people have available on their devices (more even than some new devices have free). Or want reserved for stuff 99.9999% of which they will absolutely never access. 10GB is also considerably more traffic than many can spare without incurring multiple dollars of cost. 10GB may also take most of a day to download for a great many people. People might also just want to access their stuff on a new device, such as someone else’s computer.
Local search certainly can be faster, but it’s often not. It’ll normally be using different software from what the server uses, too, since the server software is likely to be factored as a server with no direct library equivalent, and my experience is it generally produces inferior results. I know, none of this is inherent, merely typical. But back to performance: you might be surprised at just how slow storage is on cheap phones. Only a few megabytes per second is realistic, and with not enough memory to keep it in there either.
When talking of all this performance stuff, I feel like pointing out that I live in Australia and am used to the internet being slow purely because of latency to US-hosted sites. This definitely tips the balance a bit more in favour of local for me.
By all means, support downloading everything and being able to work offline and doing local search where possible. Please do, because it is better where feasible and is likely to lead to the software being better in other regards too. But for most people most of the time, requiring this is a bad trade-off.
> One still needs encryption from one’s server to another’s. To put that another way: from one’s end to another’s. Or … end-to-end encryption.
NO! This is NOT what is meant by end-to-end encryption. This is transport encryption. And note that E2EE doesn’t obviate transport encryption, because it still protects the metadata.
10GB is more space than a very significant fraction of people have available on their devices (more even than some new devices have free). Or want reserved for stuff 99.9999% of which they will absolutely never access. 10GB is also considerably more traffic than many can spare without incurring multiple dollars of cost. 10GB may also take most of a day to download for a great many people. People might also just want to access their stuff on a new device, such as someone else’s computer.
Local search certainly can be faster, but it’s often not. It’ll normally be using different software from what the server uses, too, since the server software is likely to be factored as a server with no direct library equivalent, and my experience is it generally produces inferior results. I know, none of this is inherent, merely typical. But back to performance: you might be surprised at just how slow storage is on cheap phones. Only a few megabytes per second is realistic, and with not enough memory to keep it in there either.
When talking of all this performance stuff, I feel like pointing out that I live in Australia and am used to the internet being slow purely because of latency to US-hosted sites. This definitely tips the balance a bit more in favour of local for me.
By all means, support downloading everything and being able to work offline and doing local search where possible. Please do, because it is better where feasible and is likely to lead to the software being better in other regards too. But for most people most of the time, requiring this is a bad trade-off.
> One still needs encryption from one’s server to another’s. To put that another way: from one’s end to another’s. Or … end-to-end encryption.
NO! This is NOT what is meant by end-to-end encryption. This is transport encryption. And note that E2EE doesn’t obviate transport encryption, because it still protects the metadata.