The distinctive element here is the hardware. Briar allows you to sync via local wifi and bluetooth (i.e. the range is tiny) but since it's a mesh network your message will be relayed eventually.

This device though doesn't seem to support mesh connectivity because it doesn't have this short range limitation in the first place. It uses a LoRa chip with a range of a few kilometers. The bandwidth is tiny though, for reasons that are both technological and legal. In particular your are asked to respect a duty cycle of 1% (or even 0.1%, depending on the exact frequency you're using). That's 36seconds every hour. On top of that add some cities offer LoRaWAN gateways (between LoRa devices and the internet) and the limits are even more drastic like 10 messages per day, 51 bits being the maximum payload length.

LoRa was designed for async metering of IoT devices basically. This application is pushing it to its limits I guess.

I'm not an expert, I have a couple LoRa chips but never used them, however here are some back of the napkin calculations:

Assuming a spread factor of 12 (very long rage, very low bandwith) and a 1% duty cycle, you can send about 40 messages per hour if they are short like "yo what's up". 50 chars -> 20 messages/hour. 100 chars -> 10 messages/hour.

Does the duty cycle mean it's only sending a receiving for those 36 seconds of every hour? The hermit in me is enthused by communicating with this restriction.

IANAL/IIUC, it can also be, e.g., 10ms every 1000ms, and it only applies to emission side of it. You don't have to actually put away the device for an hour after picking up once if the modem is not sending 36 seconds straight. But it does divide the data rate by 100.