This article was posted here as well. Here’s the comment I left there:

This article seems either very naïve, or fairly disingenuous. Signal is not precariously installed on one box, and if that box goes down, the service dies. It is distributed. It’s running on many machines within AWS, and technologically, there’s no reason it couldn’t be in multiple regions of AWS, or even spread across multiple clouds (e.g. Azure, Google Cloud, Oracle, etc), to improve resiliency to outages. The only way in which it is “centralized” is that there’s one foundation in charge of the whole thing. Are there drawbacks to this? Yes. But self-hosted, distributed, mesh/relay chats also have drawbacks. Servers in the mesh go down, people don’t keep things updated, they don’t necessarily connect to every other instance creating disjointed pockets, etc.

Also, to say “we don’t need the internet” we need “mesh networks” is odd… The internet is a mesh. Hence “inter.” Anything else is just a smaller version of the same thing, again with some benefits and some drawbacks.

Fighting a (relatively) successful platform that champions privacy and security, seems like a bad thing to do, when those are the same primary goals of the platform you support. It would be better to discuss the merits and use cases of each, and beat the privacy and security drum together.

In my opinion, this article is just spreading FUD. Signal is not perfect, but it’s pretty good. And when there’s an outage, we know why, and we know there’s a team working on it. With a federatated service, it may be harder to take “the whole thing” down, but that doesn’t mean nodes don’t go down, service isn’t disrupted, etc. Scaring people away from a (usually) reliable, open platform, that has been audited, that actively advances security research and keeps it’s platform secure against emerging threats, is counter productive. It’s just going to keep people using SMS and WhatsApp.

I don’t have as much experience with HASS, but I did use Mycroft for quite a while (stopped only because I had multiple big moves, and ended up in a place small enough voice control didn’t really make sense any more). There were a few intent parsers used with/made for that:

https://github.com/MycroftAI/adapt https://github.com/MycroftAI/padatious https://github.com/MycroftAI/padaos

In my experience, Adapt was far and away the most reliable. If you go the route of rolling your own solution, I’d recommend checking that out, and using the absolute minimum number of words to design your intents. E.g. require “off” and an entity, and nothing else, so that “AC off,” “turn off the AC,” and “turn the AC off” all work. This reduces the number of words your STT has to transcribe correctly, and allows flexibility in command phrasing.

If you borrow a little more from Mycroft, they had “fallback” skills that were triggered when an intent couldn’t be matched. You could use the same idea, and use https://github.com/seatgeek/thefuzz to fuzzy match entities and keywords, to try to handle remaining cases where STT fails. I believe that is what this community made skill attempted to do: https://github.com/MycroftAI/skill-homeassistant (I think there were more than one HASS skill implementations, so I could be conflating this with another).

Another comment mentioned OVOS/Neon - those forked off of Mycroft, so you may see overlap if you investigate those as well.

Fediverse… Fed… Federated. Unifying it would defeat the purpose. Yes, there could be a single platform, with federated hosting, but multiple platforms working with a single protocol is a good thing.

Consider the web - in the old days, it was an open platform. Then Internet Explorer got a stranglehold, and to use the web practically required using IE on Windows (many sites did not work in other browsers). Eventually we righted the ship, but now Chromium browsers are taking over, and we’re heading in a similar direction.

For the fediverse to remain open and effective, we should embrace extra platforms*. It prevents anyone getting too much control over the protocol, prevents lock-in, prevents centralization, etc.

*We should generally encourage use/development of the same protocol, though.