That said, it’s not necessarily easy to implement in practice. One thing about having a blog like this is that people know things about me without me specifically telling them anything. How much of my personal life stories and thoughts do I really want to mix in with my work? And conversely, how much of my work can/should I justifiably talk about here? My previous situation at the lab had few boundaries between work and personal life, so it was fine to have everything mix into one soup. But now I’m finding it harder to reconcile the two worlds, and the pool of immediately interesting material seems to have shrunk.

No doubt I’ll leave public everything I’ve posted the past year and a half, and I do intend to keep writing. I just need to redefine the goals of this journal. This is new territory here, figuring out how to thread digital identity into the ongoing changes of real life.

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

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.

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).

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.

1. Stay human by going to bed and waking up early.
2. Exercise regularly, at least 3+ times a week. I should have gone today. I will go tomorrow.
3. Take strategic breaks to let my brain cool off. Watch movies and read.
4. Stay connected with Jenn.

I’m laying it down here and now.

And it’s fine that I didn’t quite squeeze in those extra nine, because I’ve been busily immersed in actually (finally) building Promiserver, designing and implementing the core interactions. It’s not easy creating alternative populist contract systems. It has to be usable and understandable for, well, everyone. Along the way I’m also including a decent REST interface for promises, hopefully making this system decent mashup fodder.

To begin thinking about these issues, I wrote a small script that may be attached to any object, and that sends all locally overheard chat to a “Permanent Record” web application via an HTTP post. On the web, visitors may then view a list of the names and unique keys of all people recorded and all listening devices, and can view a live updating audit of all chat.

The site acts as a real time observation post of all conversations taking place within range of any of the listeners, revealing speaker identity, content, location and time. Check out the screenshot and screencast (24MB) of the permanent record and recorder in action.

I plan to put up a more permanent version of the site as soon as possible, and I’ll install a few listeners around some MIT or Media Lab sanctioned land. I’ve been tempted to attach the script to a variety of different types of objects, especially projectiles so I could launch them towards interesting things happening. It would be interesting to have these things distributed all over the place, though at some point I’d probably be violating the Linden Lab ToS.

Luis and I tested out the recorder a little…

Unfortunately he felt compelled to sit on it.

Check out the LSL source code. If nothing else, it at least has some generalized little functions for sending RESTful HTTP posts. Since Second Life only allows 20 HTTP requests per 100 seconds, my code queues up overheard statements and sends them in batches.