Leave your phone at home, back up all the important data you need into a server. Keep all important information and documents you need for the trip printed on a paper.
Go through border without a phone, buy new phone and SIM abroad to avoid roaming. Access/download your important info through the internet using the hotel's wifi.
After the trip you can bring the phone home and it will only contain some holiday photos.
For privacy purposes it's better to buy an unit in a condo, than a house. In a house your neighbors can easily look out their windows and see who visits you, whose car is parked in front of your house. In a condo it's much harder because the same main entrance is used by many people and it's difficult determine which unit a visitor entering the main entrance is going to, so it's harder to connect the dots.
You can move to any other service, but once it becomes popular enough to draw attention they might also get blocked as well. If it's centralized, then the central servers can be blocked and it's not longer working. If it's decentralized and peer to peer, then the bootstrap nodes can be blocked and it's no longer working.
Even if it's self hosted and not advertised, the adversary can run active probes to detect banned services and block it if it detects any.
The only thing that can work reliably is something that can be concealed and can't easily be detected.
A simple HTTPS website that runs a small blog, forum or an image board, can have a lot of bot traffic, and human traffic that makes the traffic analysis hard, it also provides plausible deniability if someone asks why you visit that site often, you can say that you are playing games or browse images there. Such website can have a secret interface that can be used as an interaction point for secure chatting (in a store and forward manner), which responds only if the requests are cryptographically signed by the participants, otherwise the server can play dumb and show a 404 error. Therefore an active prober can't easily detect that the website hosts that interface the first place, because they cannot produce a signed request unless they manage to compromise one of the participants.
Threat analysis:
Someone should make an app that works this way. Only one tech savvy person of the given group need to set this up (preferably someone who alredy have a website), then others in the group can be invited into it and can use it without much friction.
I think people should rediscover the beauty of doing things offline on a computer.
I had a recent experience traveling on a train. A mother used YouTube to entertain her young kid with some children video. Every time there was an internet hiccup and the video stopped, the kid started crying...
You don't need a NAS and a streaming media server or anything in cloud to watch your favorite media, or to listen to your favorite music. You can simply put them on a pen drive and whenever you need the media, plug it in and watch/listen offline. Using an OTG adapter you can even plug it into your phone (at least for the duration of the the time while copy the needed files off it). Most people don't need much more than this. And if that mother put the videos on the phone before the journey the kid would never cry.
If you need a file server, you can use a basic Linux installation and enable SSH. Then you can transfer files over SSH using Filezilla or other SFTP client. For versioning you can use Git (it's not just for programming), and the remote is just a directory on that Linux server where you have previously created a bare git repo.
Back in the day when people wanted to share something with the world they would set up a website (instead of sharing on social media, because there were no social media). When large files needed to be moved between people, Bittorrent was used (instead of CDNs, because there were no CDNs).
These still work and needs to be rediscovered and used. Perfection is reached when torrent downloads are integrated into the browser itself.
I think the main requirement for general purpose computing is the decoupling of software from hardware and allowing modularity.
The problem is that with Apple, Samsung, etc fully integrate the hardware and software in house, this means all the drivers and blobs can be kept in house secret.
On the other hand a PC can be built by anyone from hardware components they choose. In order to make this work all the drivers and blobs for all the hardware components need to be public, and therefore can be integrated into the Linux kernel, allowing anyone to use an open source OS on their system.
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.