update Several people have mistakenly thought my slightly tongue in cheek title to mean that I’m one of the part of the fringe paranoia groups here. While the USDOJ did bring down e-gold. The term “The Man” as well as the use of references to Black Helicopters were an attempt to caricaturize those paranoia groups. Now where did I put my tin foil hat.

e-gold is an 100% gold backed electronic currency. It revolutionized the electronic currency world using pretty simple double entry book keeping technology backed by currently 2.54 metric tons of gold and innovative legal structures to keep it safe. They are in the news today and there are lots of things startups can learn from their story about trust, innovation, legal structures, transparency and how not to deal with regulators.

It is with sadness I today read Douglas Jackson’s blog post outlining the final blow to e-gold by the US government. It felt like this wasn’t written by Doug, but by Doug with the NSA’s secret alien mind control device implanted. In reality the mind control device used was the threat of 20 years of jail and a half million dollar fine.

Also as I write in the Agree2 User Agreement:

We are men of principles, but stronger men than us have changed principles with 3 hovering black helicopters over them. If you know what I mean.

This is a case where probably a bit more than 3 hovering black helicopters were hovering over them. So I guess we can only feel sad and hope the best for Doug and his family.

I launched TimeCert a few years ago and haven’t given it much love since. Now I’m pleased to announce the official relaunch of it.

TimeCert is a really tiny and light web application that does one thing and does it well. It records and presents the time it first saw something. If you look at the bottom of this post you can see a small TimeCert iframe which tells you the first time timecert saw this article.

The main application of this is really for intellectual property protection. But there are also various other applications. Lets say you’ve been blogging about an idea for a while and all of a sudden someone hits you with a Patent Infringement Suit. You know it could happen. Well TimeCert provides evidence as a trusted third party that you actually wrote your blog posts when you did.

One thing to remember though is that TimeCert can’t back date any existing content. It only knows the first time it was presented with the data.

API

The API is so simple that it’s not even funny. First of all you need to create a SHA1 hex digest of the data you want timestamped. This is easy in most languages. In Ruby it’s:

require 'digest/sha1'
@digest=Digest::SHA1.hexdigest @your_data

Just perform a HTTP GET to TimeCert to one of the urls below changing DIGEST to the digest you created above:

• http://timecert.org/DIGEST for end user link
• http://timecert.org/DIGEST for use in an iframe
• http://timecert.org/DIGEST.time for a plain text file with ini style parameters
• http://timecert.org/DIGEST.ini for a plain text file with ini style parameters
• http://timecert.org/DIGEST.xml for xml
• http://timecert.org/DIGEST.yml for yaml
• http://timecert.org/DIGEST.yml for json

The easiest way to use it in a web application is to embed an iframe in your page like I’ve done here:

<iframe src="http://timecert.org/a94a8fe5ccb19ba61c4c0873d391e987982fbbd3.iframe" width="450px" height="30px"></iframe>

This saves you from manually doing a TimeCert request as the timestamp is created on the TimeCert server when the page is displayed the first time.

Best practices in Rails

To do this from Rails first create a digest method on your model:

  def digest
    Digest::SHA1.hexdigest("#{title}\n#{body}\n#{extended}")
  end

Note this is from my blog, I’ve decided that the important content in a blog article is title, body and extended. I’m also using the raw textile data to create this. This is the safest as an update to a textile library could change the digest completely and thus create a newer timestamp.

You could also create a separate digest column and updated it an before_save. I’ll leave that task as an exercise to the reader.

Next create a helper method:

  def timecert_link(article)
    "<div class=\"timecert\"><iframe src=\"http://timecert.org/#{article.digest}.iframe\" width=\"450px\" height=\"30px\"></iframe></div>"
  end

Now you can just include it in your views like this:

<%=timecert_link(article)%>

It would be great if someone with PHP/Python experience could create a similar example. I would expect it to be extremely simple to create a WordPress plugin to do this automatically, if someone is up to the challenge.

Open Source

This is not really a money making operation, it’s just a service that I feel is important to have. Therefore I’ve open sourced it and you can find it on GitHub. I think this is an important part of being trusted. This allows anyone with ruby knowledge to verify that I’m not doing anything strange. It also opens it up to potential competitors, which I’m absolutely cool about.

TimeCert is written in Ruby using Merb and DataMapper.

By now many people have heard of Nassim Taleb’s amazing book Black Swan. This book has completely changed the way I think about the world as a whole and startups in particular.

I really recommend you read the book as I can’t possibly do it justice myself. However I will give a brief overview here. Hopefully in later posts I will go on about how this all applies to startups and technology.

The Black Swan itself signifies the highly improbable. Until one was discovered in Australia, Europe thought the idea of a black swan as being impossible. See Nassim’s own video explanation here. Anyway Nassim uses the term Black Swan as meaning a highly improbable event.

The importance of these highly improbable events are that it is very hard to properly analyze and plan anything as just about any major change (both good and bad) come through Black Swans.

I’m sitting at the OAuth Summit held at Yahoo in Santa Clara. We’ve had a brief discussion about the IPR policy negotiation process that has been going on in the background between a few core OAuth people and legal departments in various large companies (most notably Yahoo, Google and Microsoft).

Briefly the IPR policy allows employees at large companies to collaborate on the standard while promising to not sue anyone who uses their companies Intellectual Property through use of the standard. So basically Yahoo can’t come sue anyone using OAuth for using some patented algorithm they submitted to OAuth.

The IPR policy is important and good work. That said the current second revision of this is essentially a secret document that will be presented signed, sealed and delivered to us b-list members of the community in a week or twos time.

The community created the OAuth Non-Assertion Covenant and Author’s Contribution License which all the original OAuth spec signers have signed with the exception of Yahoo.

Eran told us today that apparently Yahoo stalled the process in their legal department as they needed a more detailed agreement. This is fine and great feedback, however these comments should somehow be made public so we the community also can follow it and make comments.

I realize that most developers don’t want to follow this, however it is important that it is transparent and googlable. I suggest a OAuth-legal group, the same way OpenID does or a continuation of the existing IPR License on Agree2 which does offer comments, versioning and a full transparent audit trail.

One comment I was given was that we should let lawyers talk with lawyers. I have to call bullshit on that. These kinds of things are way too important to be left in the hand of lawyers without any kind of external oversight.

Gabe has been doing a great job representing us (the OAuth community), however there are lots of people with opinion on this who would like to follow it and voice occasional opinions. Those of us who are building businesses around OAuth based services need to feel comfortable that we aren’t going to be screwed by some indecipherable legalese in the future. More important if there are disputes in the future the negotiation trail is key for solving them.

The final comment I heard is that large companies like Yahoo and Microsoft don’t want to make it public that they are negotiating this. I’m sorry that is even greater bullshit, thats pre-cluetrain, pre internet thought.

Get with the program. Yahoo has more to loose by not using OAuth than us in the OAuth community have to loose by them not joining us. I’m sorry if thats the way it’s done, I don’t care. This is not the world of industrial age negotiation in smoke filled private lounges. You guys are all internet companies for god sake.

OAuth is about open transparent simple standards for creating a infrastructure thats open to all of us and not just Google, Yahoo and Microsoft. Any negotiations behind it should be too.

Update July 2nd, 2008 Here is the latest version of the OAuth Non-Assertion Covenant and Author’s Contribution License For OAuth Specification 1.0

I suppose I should write a detailed post at some point about this. But here are a couple of notes from working intermittently on Talk.org in the last couple of weeks.

First of all Python is definitely not Ruby. It is very different in many ways. So just accept that and get on with it. Ruby still puts a much larger smile on my face than Python does, but that might be inexperience.

Secondly Django is not at all like rails, even though most python guys seem to claim it is. Pylons seemed much more rails like. However I decided to stick with Django as it’s always good to learn something new.

The best resource I found for getting started was this example project Wuzhere that was demonstrated at Google IO. It is really a great guide to get your head around structuring your project. In particularly coming from Rails, I learnt way more just reading through this code than reading various tutorials on the web. A key piece of code to simplify your life as a rails guy coming over to Django is their view.py class, which acts kind of like a rails render method.

You should use the Django Google App Engine Helper if you are doing Django which is described in this little tutorial. However the approach to laying out your application taken by the Wuzhere developers seemed more logical to me than the approach suggested by the Google App Engine helpers.

Generally speaking I like the AppEngine design. The models are great even if they require you to think a bit differently about the design of your data model. I don’t see a clever way of doing callbacks on the models like with activerecord, but I suspect that something similar would be possible with clever use of Decorators

I would like to say though that while I am still a novice at Django/Python it does seem to me that there are design decisions in both that I’m not quite happy about. Once I’ve worked more with it I’ll see if I still feel that way and can formulate it a bit better.