Coelacanthus

ESPHome has supported Thread since 2025.6.0b1. But Matter support still need more time.

https://github.com/esphome/esphome/releases/tag/2025.6.0b1

https://github.com/esphome/feature-requests/issues/1430

It should be an implementation issue completely. You can read through the RFC 9700: Best Current Practice for OAuth 2.0 Security, they list many requirements to implement a secure OAuth, such as use short lifetime access token, access and refresh token should be sender-constrained, access token should be restricted to minimium permissions, and so on. The softwares you mentioned violated many rules.

https://datatracker.ietf.org/doc/html/rfc9700

I don't want each client to have a globally unique address as that just allows insane tracking.

Just for this issue, SLAAC has a privacy extension to generate temporary random IPv6 address for outcome traffic. It's untrackable as well, but in different way to NAT (one device has many addresses instead of many devices have one address).

If I go for SLAAC with privacy extensions and I keep paying for a static IP (v4 & v6) to my ISP then I can't implement any firewall rules for specific devices as devices will change their IP regularly. And its even worse if I don't pay for a static IPv6 prefix.

I don't know which firewall software you used. But if you use nftables, which support suffix match and conntrack for TCP/UDP, you can block all new (identified by conntrack) income (since privacy extension design for outcome) and allow income with specific suffix (for SLAAC with EUI-64, it will stable), needn't care about which prefix was used.

For example, something like epub is going to be hard because the format is really just a zip file with a specific internal file structure. So, it's not really the .epub file you want to grep, but one of the files within that zip file you want to grep through.

ePub is a zip file contains a batch of HTML file for contents and some XML files for metadata. So you can extract it and do grep as you do for HTML files.

So when they will change this horrible hardcode font fallback list with "normal" font fallback mechanism like Fontconfig?

https://github.com/pop-os/cosmic-text/blob/main/src/font/fallback/unix.rs

I like the screw in connector because I don't have to worry about it falling out of the PC or monitor, and it is more robust, less likely to be pulled/bent/broken.

But with screw, when something dropped, it may pull the whole connector socket from the machine... My friend's monitor was broken because of that.

I suppose displayport over thunderbolt plus embedded USB hubs in computer monitors gets close, but the display settings controllers usually require proprietary drivers and are vendor specific.

DisplayPort have DDC to control display settings. But I don't know how much settings was standardized and implemented by vendor. But at least, the backlight was implement by most vendors, many users use it.

Raspberry Pi Zero 2 can run Linux. So you can run mail client on it of course.

What ever DisplayPort do, HDMI do more badly. HDMI also requires Annual Fee to get document now (since 2021, before that the document was public available). And this is not the worst thing, the worst thing is the HDMI forum disallow anyone open source a driver which support HDMI 2.1 or higher.

https://gitlab.freedesktop.org/drm/amd/-/issues/1417#note_2303163

It's difficult to have. The members of HDMI Forum are almost the TV manufacturers and the members of VESA (the maintainer of DisplayPort) are PC and GPU munafacturers. So TV almost uses HDMI and monitor almost uses DisplayPort.