This really needs a showcase of internally built use cases for human.io that I can play with right now.
I assume that: developers can create a micro-app with a dead simple API ... users run and discover these micro-apps from within the human.io mobile application.
An example micro-app would be where I create a bookmarklet that grabs an image, it sends it to human.io with the text "please identify this shirt" and then a human.io user can choose to run and solve that "micro-app"
It's confusing because micro-app implies repetition, whereas they are more like tasks: they have a "completion." This is a more powerful, easier to use, mechanical turk where the turks are on mobile.
None of the "things you can do" lend themselves to justify me having to host the micro-app - eg, they do not tell a story of needing to pull in additional application logic: was it a conscious decision not to build an IDE and hosting environment for human.io so I could just jump straight into building micro-apps?
We built the assembly language; the ide/hosting/etc would be a layer above that.
The events are pushed back to a webserver, and you decide what to do there. If you already have an application and data storage etc already, this is basically the easiest thing to do. We felt this flexibility would lead to the most interesting initial apps; additionally, the vast majority of early adopters would probably not love being sandboxed.
 we also have a hanging HTTP api; call /next_event and it hangs until it has events for you. this lets you talk to the system without having a public open port.