I like this idea so much. The problem is quality control.
Uber Eats here in UK really struggles to delivery an accurate order. And where there is a problem the driver blames the restaurant, the restaurant blames the driver, and Uber or the restaurant (it’s frequently not clear where to begin) may or may not issue a refund and perhaps an apology, but that doesn’t solve the problem which is you don’t have the food you were promised and that you paid for. No one takes responsibility for that.
Who in a decentralised system can or should take responsibility?
Amazon, for all their many faults, claim to be trying to make the most customer-centric company on earth. A lot of their early success came from a stellar returns policy, shouldering responsibility for products they dispatched, as well as excellent prices. Not so much now, but certainly during their incredible retail growth period.
How do you code for that in a federated system? And, if you can, how do you compete in a wider marketplace with an Amazon monolith?
This works very well with OpenWRT on each AP and/or router device by using the same ESSID and password combo on each of them, enabling WLAN roaming and also 802.11r Fast Transition to allow your mobile devices to hand-off quickly from one AP to another as signal strength levels demand. With this enabled you keep the same IP address, and even SSH sessions don’t drop when you move from one AP to another, it all happens in the background. As far as the end-user is concerned it is all just one big happy wifi network.
802.11r is not mesh, that’s a separate thing but and you can do it with OpenWRT too. I don’t need to because I have ethernet to all my APs, so all the RF bandwidth is available for the last leg from AP to device(s), and not being used by back-haul from AP to AP through to the router as well.
In your use case I would consider grouping devices into categories and having a different wifi network for each category with the dhcp and firewall rules set accordingly.
VLANs on the ethernet-side might also be useful, but it sounds like most of your devices are on WiFi, so it might well be possible to get a “mature” setup without needing that extra complexity.
As others have said, backing these settings up and restoring them to a new device in the case of hardware failure is generally straightforward. Care is needed when replacing the broken device with a new one because of naming conventions varying from device to device, but the network logic, and things like dhcp reservations can be carried over.