There seem to be two parts to this. One is a way to inventory your LAN using multicast DNS and find all the web servers on it. (There may be one in every lightbulb.)
The other is to run a web server in the browser. These are independent functions.
The first seems useful. The second seems to need a more compelling use case. Also, opening the browser to incoming connections creates a new attack surface in a very complex program.
FYI, the first part isn't new. Safari already uses mDNS to find webservers on your LAN. For me, this is also supported by my printer, so I can just go to the Bonjour bookmarks to find the admin interface without having to remember its IP address.
What is new (and what appears to make Mozilla's implementation incompatible) is that they are adding a layer of UUIDs to ensure each service gets a separate origin. This ensures that, if you switch between LANs, an open tab for one device can't interact with a device on the other LAN with the same name or IP address. Makes a lot of sense for the security of IoT devices.
The UUID approach was a stopgap to solve the same-origin issue in the short term and stand up a simple prototype proof of concept.
Longer term, I think we'll need to use a separate URI scheme (e.g. fly://). It turns out upon further investigation that the (http://) scheme relies heavily on TCP semantics. For example, port numbers are an implementation detail in flyweb, not something explicitly exposed via URI, but http demands that port numbers be interpreted (and without a port number, an origin assumes port 80).
We also want to restrict the underlying wire protocol to be a subset of HTTP, eliminating a number of the purely internet-related functionality, such as redirects and proxies.
We also need to specify different security semantics for interpretation of TLS certificates in the FlyWeb context. Devices are not websites, and they're not identified by internet-DNS names, and the current certificate model is oriented to work with that design.
We're slowly working through resolving all of these issues. The idea is simple, but the execution requires care and attention to detail.
The first seems useful. The second seems to need a more compelling use case. Also, opening the browser to incoming connections creates a new attack surface in a very complex program.