Promiserver: Procedurally Executed, Socially Enforced Microcontracts
(100 pages, 12MB PDF)

With the sunshine comes relaxation. I’m shedding my winter and springtime worries, handing over theses for signatures, and feeling a little more comfortable. It’s hard to distinguish where the sun and warm breezes end and where my own reemerging sense of satisfaction begins.

The other news is that I resuscitated OPENSTUDIO today, putting it on our newer server, which also involved switching it to apache2.2 and mongrel cluster instead of fastcgi, and setting up Postgres and PHP, plus some Tomcat fiddling. Way too many technologies happening in that project.

1. So far promiserver people tend to write promises for themselves alone. Why do you think this happens? What would make people focus on writing contracts among themselves and other people?

This is a good, open question. It may be simply the terminology “promise” makes people think that if they write it, they are the participant. This has been a confusing point for almost everyone I’ve tested this with. A few reviewers were very confused about why they needed to put anyone in the promise at all. I don’t have any solid answers here. People may also be timid about publicly asking other people do things. I also think no one really even knows what sorts of promises to make.

2. When does promiserver evaluates/runs a promise? I see the Audit Trail evaluation list. But It is not clear what is the order or logic for these evaluations?

It evaluates active (signed by all participants) promises every 5 minutes, and also every time values are updated. Every value update is also logged, though this part of the audit trail is not yet visible.

3. I think promiserver needs ultra-light remote interfaces for entering / updating values in the contracts. This might be SMS interfaces, email commands etc.

I agree. I was working on the API for this yesterday. It is close, I just have some authentication/permissions issues. I probably won’t have time to work on it again until mid-May. Once there is a simple REST API then other interfaces can follow (widgets, email, physical/sensors, etc).

Thanks again to Burak and everyone else playing with this thing. Sorry the system still has a few bugs here and there, but we’ll work ‘em out. It’s been so rewarding seeing you all make your accounts and test it out. It is motivating me to finish writing.

And special props to Carlos Rocha for his random promise. So awesome.

Breach and Success

There are two reserved methods: breach and success. Each takes an optional message parameter. Your code defines the conditions under which the promise breaches or succeeds. For example, a really simply promise would be:

if condition_x
  success "it happened!"
end

The value of the condition_x variable determines whether the promise evaluates to success. When condition_x evaluates to true, the promise will be evaluated as a success, with corresponding message “it happened!”. A marginally more sophisticated promise might look like this:

if condition_x
  success "x happened!"
elsif condition_y
  breach "sorry, y happened"
end

In this one we have possibility of a breach as well, if condition_y evaluates to true.

Promise State

Those variables like condition_x and condition_y aren’t defined anywhere in this code. This means that they are free variables.

All these free variables in your promise code are extracted as you write the promise, and together form the state of the promise. When writing the promise, you can change the values of these variables to the desired initial state. Once published and signed, all participants can also change the values of these variables.

Time

Most promises are commitments with respect to some future action or event. So it may make sense to take time into account.

if document_received
  success "thanks, nice work"
elsif  Time.now > document_deadline
  breach "missed the deadline
end

Again, document_deadline and document_received become promise state variables, meaning they can be changed by the participants. If we wanted to fix the deadline and remove it from the state, we could simply add in a line.

document_deadline = Time.parse("5/11/2007 6:00pm")
if document_received
  success "thanks, nice work"
elsif  Time.now > document_deadline
  breach "missed the deadline
end

Keep in mind that Time.now evaluates differently each time the promise is evaluated. Future versions of Promiserver will have a timeline or calendar view, to try out the code for different times in the future.

Ruby Niceness

Since we’re using Ruby with some special activesupport magic, we can use some cool shortcuts. For example, say we want to allow for an extension:

...
if Time.now > (final_date = deadline + extension.days)
  breach "missed the extended deadline #{final_date}"
end
...

This is just a starting point. I have a few people using the system now, and in particular Burak has been a great tester, authoring some promises that have pushed Promiserver a little our of its comfort zone. So we’ll see how this contract-as-code idea continues to develop.

1. Start humble and iterate, rather than proudly setting out to build a complex system from scratch.
2. Continually get feedback from the smart people around you. Make an effort to develop an honest rapport with your peers.

More lessons to come, I’m sure.

Check it out: promise.media.mit.edu. Borrowing the slogan from OpenCode, This is so alpha, you won’t even want to use it™

Well, it’s been a while coming, and now I have a super alpha version of Promiserver live and ready for you to make all your programmed commitments with that same desperate, wanton abandon we saw in the early field tests. It’s got bugs aplenty, as well as interface problems, but I can fix em as we find em. Tags coming soon, plus REST API for creating promises programmatically, which is where I think a lot of the applications will be. A lot of other updates too, providing I have enough time given this whole writing ordeal I’m still in the middle of (sigh).

Yet as hardware gets faster, it becomes easier for programmers to achieve this real-time performance for even very complex processes. As we enter into an era of software-as-service, as we increasingly depend on data and processes running continuously and consistently on remote servers for years at a time, I argue that we are beginning to develop a different criteria for our code.

I previously referred to this idea as slow computing, but I think Lifetime Computing has a better ring to it.

Meaning is fundamentally social and cannot be reduced to the meaning-giving activity of individual subjects. The rationalistic view of cognition is individual-centered. We look at language by studying the characteristics of an individual language learner or language user, and at reasoning by describing the activity of an individual’s deduction process. Heidegger argues that this is an inappropriate starting point—that we must take social activity as the ultimate foundation of intelligibility, and even of existence. A person is not an individual subject or ego, but a manifestation of Dasein within a space of possibilities, situated within a world and within a tradition. (p33)

I left Symbolic Systems frustrated that I was only getting one side of the story. The core assumptions of the program didn’t sit well with me, but I was unable to create or find a convincing alternative that satisfyingly rejects the cold, depressing objectivity of cognitive science. Six years later, working on the background section of my thesis, Hiroshi encouraged me to look at this old, classic Flores/Winograd book, mostly because of its use of speech act theory. I’m not far into it, but so far this book is a gem, and a really interesting introduction to Heidegger, who I never read in college and probably should have.

Consider a basic laissez-faire market model in which each party tries to maximize its own gain, and in which their is no trust between the parties. There will be many cases like the Prisoners’ Dilemma in which cooperation is the optimal group strategy, but the individual strategy is uncooperativeness. A promise institution can change these outcomes, aligning the individual’s best interest with the group’s. As an outside force acting on the participants, the institution uses some condoned enforcement mechanism to deter breach of promise and incentivize cooperation.

The character of the promise institution may vary considerably. We can divide the set of institutions into two core classes of social and legal. Each operates differently, yet they overlap considerably in their scope. We rely on the social promise institution when we make promises with friends or family, or within a community. These are agreements that we would never expect to go to court. The social promise institution uses emotional, interpersonal, and community enforcement, such as gossip, guilt, shaming, or decrease in standing or reputation.

We invoke the legal promise institution in matters of government or business, where the social enforcement lacks sufficient scope or strength to ensure cooperation. The legal institution offers the greater trust firepower needed to deal with corporations and governments, yet at a cost of higher barrier to entry and far greater stakes. Participating in a legally binding contract generally often involves lawyers, fees and time for at least one party, and potentially severe legal ramifications for breach.

Promiserver lives in the social end of the spectrum, but cautiously dips its toes into legal territory. Enforcement is reputation based—clearly the social promise institution—but it aims to extend social enforcement further into the space in which people would traditionally feel the need to turn to the legal institution.

These promise institutions are critical, to both life and business. The more we trust the accuracy and efficacy of the institutions, the more we may trust in the promises we make. If I trust my community and feel they are fair and reasonable, I am more likely to make a social promise. If I feel the legal system is fair and reasonable, the more trust I place in the contracts I sign. In either case, good institutions incentivize cooperation.

Yet these institutions are not owned by any person, company, or government. They are created and owned by all of us as members and participants. Though at times the individual best interest may run counter to the enforcement laid out by the institution, the purpose of the promise institution is to protect the best interests of the group as a whole. If a corporation bribes a judge, thereby corrupting the legal institution, it may temporarily serve the best interest of that corporation, but in the long run it hurts everyone because it adversely affects our trust in the institution. This sort of “fragile, owned by everyone, benefits everyone” resource is classically referred to as the commons.

This line of thinking has reaffirmed for me that Promiserver is dabbling within a critical space. I’m currently reading Peter Barnes’s interesting Capitalism 3.0, which makes a case for creation of new policy to protect endangered commons like the environment using market incentives, and has me interested in how we approach other, intangible commons. So I’ve stepped onto this ride that is my thesis. It’s been a little slow and creaky on the uphill, but it is leading to something, and I see some interesting curves approaching.