Life & Research Notes

Good friend and PLW alum Burak Arikan posted a comment with some interesting questions and observations about Promiserver. I’m on full thesis mode today, and these issues are very much in line with what I’m thinking about.

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.

featuring “…a sonar metabolic transducer for maximum data existentialization.” on youtube, via reas.

This post is my first attempt to explain how to write Promiserver code. This will eventually also find its way into a Promiserver help section, but I thought I’d try it out here first.

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.