I agree. We focused on the controller use case as it made for a simpler API, but it was always my interest to make it more generalized. Just perhaps through a d

I agree. We focused on the controller use case as it made for a simpler API, but it was always my interest to make it more generalized. Just perhaps through a different product that was more open and generalized. Things like having your phone cache webapps that could be casted over LAN (thus not requiring a persistent connection), this would useful for playing say games/apps when on planes or log cabins, etc. Or having the phone create metascreen, synchronizing multiple monitors with fullscreen webpages open that you would split up the graphics of a game or movie to run across all the screens, thus making a bigger screen. So many possibilities. Ultimately though, I'm still on the fence to if this is the best approach vs a mixed approach of using bluetooth, zigbee, wifi, http, websockets, normal sockets, and etc all abstracted to use whatever each device has to offer.