Yes, the local client part is clear. But for the server part to be self hosted, the vendor would need to know how to reach you / your device.

Currently, they only go "hey, I have a message for user "Justin “! Google, can you make sure they get it?”. And Google takes that message, figures out which backend server your phone is currently connected to, routes to that server, the server hands it to your phone, and then you get a nice ad about CandyCrush or whatever.

If you were to host your own server, there would be an additional layer of figuring out which backend this message needs to be routed to. And for that, every vendor would need to maintain a list of backend and which users / devices are using which. Or, a third party (Google?) would need to offer a service that does this part for the vendor.

This would technically be possible, but as far as I know is not a part of the current “standards” for push notifications.

How would that work? The provider / vendor of whatever app or service you are using would need to know that they need to contact that server to send a notification to your device.

Interesting points, I’ve definitely run into memory constraints which resulted in completely unresponsive hosts a few times over the years. But as the author said, I don’t see this changing within any another of time due to the large scale archetectural changes required… The author also mentioned “I’m tempted to abandon using Windows, macOS and Linux as the main platforms with which I interact.”. Does anyone know which “daily driver” compatible operating system the author could be referring to?

In the end it depends on your risk profile and adversary model. Usually it’s not a good idea though. Why not have an SSH tunnel to the network/machine and use port forwarding to forward the RDP connection? Or why not use SSH for remote access, period?

Might be for time synchronization in order to not have to rely on a public NTP server.