The current Internet of Things (IoT) is a shadow of what it could be. I've named it The CompuServe of Things. As an antidote to the anemic IoT model we use now, I've proposed social things cooperating with each other in trustworthy spaces I call "communities of things." I've written about the importance of culture in creating these communities.

The things in these communities are more properly thought of as spimes, than networked devices. They might be networked devices, but they needn't be. If you've followed my work, you'll recognize many concepts from SquareTag and Fuse at work here. I've got a group of students building out spimes and communities on top of our pico platform.

Promises

One of the questions I've been wrestling with is how spimes work out agreements within a community. Serendipitously I ran across Mark Burgess's work in promise theory. Mark has laid out some very important principles for how we can design systems that cooperate. And cooperation is the foundation of an IoT that isn't anemic.

I can't hope to describe promise theory in a single blog post, but I do want to introduce some of the ideas. In promise theory, a promise is a declaration of intent that recipients can use to understand better the promiser's behavior. A promise is different from an imposition, a restriction placed on one actor by another. Promises recognize that actors are autonomous and cannot be coerced or forced into a certain behavior. Promise theory is a model of voluntary cooperation. That's a pretty good description of what we want from communities of things.

An imposition attempts to force the recipient to behave in a specific way. The system imposing obligations must understand the capabilities of the recipient. Obligations separate intent from implementation, creating uncertainty. An actor receiving obligations from multiple sources has no way to resolve conflicts.

In contrast, actors that make promises are declaring their intent with respect to some behavior. The actor knows it's context with and uses it to make promises. Promises can come into conflict, but the actor who issued them has the context to resolve them¹.

Promises require that the promisee evaluate whether the promiser will keep the promise or not. This put the responsibility to plan for failure on the promisee. Some promises are more likely to be kept than others. Promises bring uncertainty to the foreground. This idea fits nicely with our intention to use reputation in creating trustworthy spaces.

Promises and Picos

Promises are a great complement to our pico-based model of programming. We can think of each pico as a collection of promises in the form of the rules that are run in response to events. "When I see event A, I promise to do X, Y, and Z."

We can visualize pico A having a channel to pico B as a promise by pico B to accept events from pico A. We can restrict channels so that the promise is more specific. Pico B promises to accept events of types X and Y from pico A. Note that the point-to-point nature of event channels in pico-to-pico communication (rather than using a global event bus) helps preserve pico autonomy by letting picos determine what events they'll accept from which picos.

Promises and Communities

One of my examples of a community is the problem of an electric car negotiating charing times with other appliances. But that gets pretty complicated. So let's start with something simpler. Fuse has the notion of a fleet, which is essentially a community pico for the vehicles (spimes) in the fleet. The fleet community pico makes the following general promises:

• I promise to evaluate request to join the community
• I promise to identify members of the community to each other
• I promise to aggregate member information for other interested parties
• I promise to only release member and aggregate information to certain parties
• I promise to route certain events to the owners' picos

These seem like a good set of rules for any community. Specific types of communities might have additional promises implemented as rules. For example, I could imagine communities that jointly share a resource. These promises might include:

• I promise to maintain authorization credentials for an API all the members use
• I promise to accurately report resource usage to all members of the community and the owner
• I promise to notify members of resource availability status
• I promise to allocate resources fairly (or in accordance with some other scheme)

For their part members of a shared-resource community make certain promises as well:

• I promise to accurately identify its needs to the community
• I promise to use resources in accordance with allocation

Being able to identity the promises every community makes and the promises that specialized types of communities make is an important step to writing the code that makes a community function and structures the code as functionality that can be layered.

One of the challenges of building promise-based systems is behavior emerges from the promises and the interaction between actors rather than being read linearly as in an imperative program. Consequently, developers of pico-based systems need good monitoring to provide them with a "god's-eye view" of the interactions between picos and the overall state of the system. Otherwise, they can be difficult to debug.

Conclusion

I was excited when I ran across Mark's ideas on promises because it seemed to mesh nicely with what we're trying to do at the Pico Lab. They have provided a nice mental model for thinking about the interactions of autonomous agents. For example, when thinking through the promises that a shared-resource community might make, it's tempting to think of a promise like:

• promise to not let community members go over their allocation

But this either implies that the community pico controls the resource and can thus cut a member off or it is an impossible promise since the community pico can't control the members. You have to think carefully through the pico's capabilities to understand the promise it can make.

I'm looking forward to delving deeper into this idea as we start implementing the code for community picos.

1. You might recognize from this description a parallel between promises and event-based systems in that they both favor semantic encapsulation of actor capabilities.