I don't use the home assistant integration, but my understanding is you have to configure WiFi and an MQTT server on a node at your house with the meshtastic app (I probably wouldn't use a T-Watch for that, something with a longer external antenna would be better), and point it to your home assistant's MQTT server. Then there's some more configuration to make home assistant send messages and what to do when it receives messages.

Most meshtastic compatible devices do have a USB port that presents as a serial interface though, so there's probably an unofficial integration that makes use of that too.

So it can do voice calls?

Not over meshtastic, and not with the meshtastic firmware. The T-Watches have WiFi & Bluetooth, and are designed to be programmable. So the speaker and microphone could be used by custom firmware to do whatever, like talk over WiFi or answer calls on your phone.

Was I right about just getting two watches for communication?

If all you need is simple text based messaging then yep.

Is there a good crash course on understanding this stuff?

There's quite a few resources and videos on meshtastic. For the T-Watches themselves, AFAIK not really.

it has a camera and microphone, so can you actually do video calls?

I don't think any of the T-Watches have cameras. But you're right about the meshtastic bandwidth, it's more for some simple messages.

So if the network isn't great here I assume I can put up my own node.

Yep, and a node is just another LoRa device, like the T-Watch. If it's just near your house, it should work great. My Wio Tracker L1 picks up a repeater on the other side my suburb, and that gives me some crazy range.

It doesn't sound like you do, but if you need intercity range, LoRaWAN might also be worth looking into. In Queensland, many city councils (Brisbane, Gold Coast, Moreton Bay) have their own LoRaWAN networks that peer with The Things Network, and you can integrate it with Home Assistant using an integration, or my preferred way is through MQTT. You would probably have to write the firmware yourself with this option though.

There's also no livepatches from Ubuntu Pro, and I thought this was the whole idea of livepatches, to patch critical bugs before you have a chance to update the kernel.

This also isn't the first time I've been annoyed at Ubuntu's response time. Luckily I mostly run Debian, but I certainly won't be using Ubuntu for anything else in the future.

I heard a theory that the horizontal stabilisers on the tail may not be there through.

AI; Didn't read. It's the AI version of tl;dr (too long; didn't read).

Well you can't sign new certs (with the current date) with an expired root/intermediate cert, but the root/intermediate cert expiring doesn't strictly invalidate the already signed certs.

But I was more talking about the end-user certificates in the previous comment.

Yeah, my understanding was they're not issuing new certificates, but the current ones are still valid until they've expired.

FYI, G3 is the only one listed with the issue, the others are fine AFAIK. But if you don't trust eMudhra at all after that, then that's fair.

Edit: Actually it's the intermediate certs that are compromised, the roots are still fine, but many of them come from the G3 root cert (and Sectigo's AAA Certificate Services)

Source: https://emudhra.we-have-a-problem.com/

Fluxer are also moving away from LiveKit, so hopefully that means it'll require less ports soon.

Actually yeah you're right. I reread the post and their point was it wasn't easily exploitable, not that it wasn't exploitable. Which makes sense when LiveOverflow wasn't able to bypass ASLR.

LiveOverflow kinda debunked this