Earlier quoted context omitted.
Sure, but 40 years have passed since then and 144K peanuts for any real world application. A quick example, you have a sensor that sends a single metric every minute. Suppose that you can pack that info (sensor id, metric type and data) in 32 bytes. You're looking at about 1.2MB/month of data (8 times your 144K), which will come to about $40/month. Quite expensive for a single data point, but I can imagine several us…
Up to the minute sensor data for something so remote that it needs a satellite uplink is either going to be for something incredibly critical or totally overkill and a waste of money. With Swarm, you could be waiting up to 2 hours between passes that last anywhere between 10 and 50 minutes so it's not like you'll have your data instantly for large portions of the day.
But I get your point, also you can always do a lot of things to save on bandwidth, like do not send info which is not interesting (i.e. no point in sending 100s of "no fire was detected" messages).
Btw, anyone here knows if there's compression schemes designed specifically for small data packets? Gzip and others would be overkill as headers vastly exceed payload size. Just using raw LZ77 may work but it's 2022 so there's probably a specific thing for that already.
Also, what about data that follows a specific format, like only integer numbers, it would be nice to have an algorithm that takes a "string" of 32-bit ints and gives you back a binary buffer with a smaller lossless representation of it.