You can communicate effectively over 2400 baud if (and only if) you use protocols and services designed for low bandwidth; luckily we have those protocols built and tested, even if we have mostly abandoned some of them.

GPG-encrypted email over plain POP would work; and you can have automatic "remailers" on both sides of the link that handle the encryption/decryption once the communications are done over a "normal" connection.

With this slimming approach you also wouldn't use these grotesque "... and here's a portrait of my dog" type certificates we sometimes see, that may be several kilobytes in size, nor use the lengthy RSA keys. You'd do the minimum possible certificate for a single name and an EC key.

So it'll probably cost ~1kB on first connection and then only a few hundred bytes on subsequent connections, without any special components, this all just works with generic software you already have if configured appropriately.

You can shave a little more off if you agree to custom configure everything since the proof-by-certificate isn't mandatory in TLS per se, you can do everything with shared keys if you agree out of band what those keys are. This is intended for IoT-type applications.

While you might feel that it's deprecated (says who?) it's certainly in use, even by those "security people".

In the late 90's I did a lot of my grad school coding and implemented a website for a state agency though 9600 baud modems. EMACS was great in those days, precisely because it's a Lisp machine OS masquerading as a text editor. I used to read USENET news, read my email, do my work, shuffle between multiple remotely logged in shells, all through EMACS.

Wonder if it would make sense nowadays to send world state updates to clients at 1000 Hz or if it's even feasible?

p.s. the story of Iridium and how they recovered is quite amazing.