Incoming mail: my own server and my own domain (Postfix). Sufficient to receive confirmation mails and notifications.
Outgoing mail: no good/reliable solution yet. I have to send personal e-mail very very rarely.
Calendar: Tasks.org app, used offline (not synced).
Drive: 1TB external HDDs. GPG encrypted backups of important stuff are uploaded regularly to one of the VPSes I have.
VPN: Tor
Password manager: KeepassXC (with backups at 3 places).
Documents: Stored on computer, important ones are backed up. Confidential ones are stored on an encrypted LUKS volume which I only mount when I need something.
In general things I need on the go (e.g Calendar) is on my phone, the rest is at home at my computer. If I need to move data between devices I simply use USB drives. I don’t need no cloud sync of anything.
Technically any digital solution that allows anyone on the internet to send you data is a suitable replacement for e-mail.
Simple examples: sending a POST HTTP request to a given http or https URL; making a TCP connection to a given endpoint, sending the data then close the connection; making a TLS connection to a given domain and port, and send the data, etc.
The message format would be the same MIME stuff that e-mail uses, and the extensions that allow signatures and encryption.
Then the client that can send the messages would need to support at least the most common schemes, support should be able to be added to it using plugins.
A meta protocol should be made that allow clients to communicate with different solutions. Using an URI would be a good idea to identify the different protocols. Using the examples above the http post would use http: or https: URI scheme. The plain TCP one would use tcp: scheme. Plain TLS one would use tls: scheme, etc. If you want anonymity you would then use an .onion domain in the URI, or .i2p or something.
I’ve talked about this many times, but even technical people don’t seem to understand the point because EmAiL JuSt WoRks (except it doesn’t, due to deliverability issues and IP reputation). The point is that you would have total freedom to decide where and how you wish to set up your digital postbox (a postbox, not an account at a platform or in an app!).
The above method can be used to allow people who use different protocols to communicate.
If Alice decides to use a HTTPS post form, while Bob decides to use plain TLS. Alice can then use plain TLS to send message to Bob. But then Bob can post to Alice’s https form to respond. They can do so because the client they use knows what to do based on the URI. Alice’s URI would be a https one, Bob’s would be a tls one.
This seems to be unthinkable in all of the current messaging systems that require all users to use the very same protocol and even require users to have account on the same platform with the same provider.