In my experience, a major sticking point for Home Assistant (as compared to most off-the-shelf cloud-based competitors) is the ability to connect to the frontend off-site. This currently requires port forwarding, however that requires additional effort and technical skill, and may not even be possible on some ISPs (e.g. carrier NAT). Furthermore, a dynamic IP requires a domain name, and most DNS services don’t offer a plug-and-play solution; one must set up an account manually. However, LibP2P appears to solve these problems quite handily; it will automatically try to set up port forwarding if possible (UPnP, etc.), and will fall back to NAT traversal and relaying via other nodes if necessary. The Home Assistant server would incorporate a LibP2P node (perhaps Kubo, which is the official implementation), and the frontend would connect to this via an embedded JS-LibP2P node. The mobile apps would also need to include LibP2P nodes themselves so as to operate in this manner. This would effectively replace the current websocket connection with a LibP2P stream, letting LibP2P itself handle all of the networking details needed to establish the connection from practically anywhere.
In addition, the frontend itself (including its embedded JS-LibP2P node) could be served via IPFS (a content distribution network built atop LibP2P itself), or more specifically IPNS (which uses cryptographic keys to create a sort of decentralized domain name system, albeit with gibberish names). Public IPFS gateways currently exist to allow normal web browsers to load IPFS/IPNS sites, though there are plans to integrate IPFS support directly into major web browsers in the future. It would need a way to direct the user to the rather long and nonsensical domain name during onboarding (perhaps a QR code if the server has a display, or a .local site with an HTTP redirect, providing a similar experience to the current implementation). This would put Home Assistant on par with existing cloud-based solutions in terms of user convenience (actually better since they wouldn’t need to even set up an account), while retaining the freedom and privacy advantages of local operation (even when used off-site).
This also opens up some rather interesting future possibilities, such as software updates via IPFS, or the use of multiple interconnected Home Assistant servers in one home.
Please note that this feature is likely to require a non-trivial overhaul of both the Home Assistant core and frontend, as the current implementation appears to have extensive baked-in assumptions about the use of a websocket as the primary API. Alternatively, some sort of translator daemon could sit between Kubo and the existing Home Assistant server, connecting to the latter via an actual websocket (note that the frontend would still need to embed JS-LibP2P). We would also need a solution for various integrations that currently expect to be directly accessible from the frontend via HTTP.