That is kind of what Nest's Thread protocol allows IoT devices to do. But strangely enough, Google is going the opposite direction with its devices, including coming up with such stupid ideas of controlling your (OnHub) Wi-Fi router over the Internet through an app.
Thread is just an IPv6 wireless mesh routing protocol right [1][2]?. On its own it doesn't solve 2 key security problems:
* Any device can send arbitrary data to somewhere on the internet
* Internally, any devices can send arbitrary data to any other device
-----------------------
Another less-critical but important usability limitation is the short sighted nature of how device logic + APIs will evolve long-term for Device-to-Device communication.
Device-to-Device implies the application protocols are running on the devices themselves, which can't be bugfixed or upgraded by the user and in the majority of cases will likely never be updated by the manufacturer after release.
In [2] they give examples of devices like fridges and thermostats talking to each other. There's 3 long-term ways I see of handling device-to-device application APIs:
* Option 1: Raw device-to-device (Short term): How the hell will those APIs be agreed upon and evolve across multiple years and device products? Bluetooth now barely handles relatively simple interop use cases (files, contacts, audio...). Will Thermostat X support Fridge Protocol 8? How will the user handle more advanced use cases?
* Option 2: Vendor managed (Currently the most likely): The devices will talk to the vendor servers which will talk to other vendor servers which will talk to your other devices. Terrible for the user for so many reasons but great for the vendor: its the simplest to implement, keeps protocols secret and locks user into giving that specific vendor endpoint all that juicy data.
* Option 3: User managed (IMHO Preferable): Computer drivers are a much better model for this. Drivers sit over devices to transform the weird device API (fixed target) into a consistent interop API (community driven moving target) that does what people want. This still supports device-to-device: device A -> API call on gateway driver A -> gw driver interop API -> API call gateway driver B -> device B. This is what Option 2 (vendor managed) will actually have to do under the hood anyway. This could be implemented in a simple way e.g. with per-device(type) containers exposing a TCP/UDP port to the device.
I predict Option 3 to become mainstream when the year of the Linux desktop lands :D
