Last week we saw the launch of Tipit.to, the Dutch startup by Reinier, Jeroen and Alper. Tipit is a webservice that allows anyone to give a small tip (starting at 1 cent) to anyone. Tips are aggregated before payed and a similar system is used for payout. This makes it way more easier to pay a tip using Tipit than having to go through the PayPal process for every 10 cents you want to pay someone.

Why tips?

So why would you leave tips? Well honestly there are numerous reasons, but I always like to think about it as a good anti-advertisement measure. Most sites show Google Ads simply because the income they get from it pay for the server bills, which doesn’t mean they feel happy to have to show their users advertisement. Instead, a Tipit button on a website could allow users to make simple and easy donations, eliminating the need of advertisement.

Creative uses

There are obviously other reasons to have a tipjar besides preventing advertisements, and since the launch last week we have already seen a few uses that were pretty creative. The most notable is Lauren, who’s house burned down and is now looking for some money to get his life back on track (photos and videos here, or tip him here).

How to join?

Setting up your own tipjar is pretty easy, just go to Tipit.to, sign up, create a tipjar, and place the nice button on your site. In contrary to other services like Paypal they don’t need an awful lot of info about you before you can set up an account, and in contrary to services like TipJoy they pay out real money.

Is tipping the future?

I personally think we will see more and more tipping in the future. Tipping is the logical extend of the currently increased social activity on the web. Recent research shows that people are clicking less and less on advertisements and honestly I think we all hate to see them around anyway. Add on top of this that many people are starting to feel more and more invested in the sites they use day in and day out (see Flickr users vs the Yahoo/MS news), and tipping is definitely going to be hot in 2008.

This is a -very- technical post, so if you aren’t a programmer you may not be able to follow along.

Regular Expressions are used in virtually all webservices. mod_rewrite, a very popular apache plugin, uses them. Django, a popular Python web framework, uses regexps to map URLs onto the code that can handle the requests. Perl is virtually built on regular expressions. Virtually all languages popular for web development support regexp parsing.

Unfortunately, certain regular expressions have what I call ‘runaway nature’. A regexp with ‘runaway nature’ has the following property:

There exists at least 1 input string which will cause the act of matching this input string against the regexp to take a very long time.

Simple example: Given the regexp (x+x+)+y and the input string xxxxxxxxxxxxxxxxxxxx, most regexp parsers just hang. Smart ones realize this can’t work (as all matching strings must end in a y, but the input string does not. Unfortunately most aren’t that intelligent). Turns out on e.g. the C# regexp parser, an average powerful machine needs 25 SECONDS to realize that the input does not match the output. See This codinghorror article on the details of this particular case. Clearly the regexp (x+x+)+y has runaway nature, at least on the C# regexp parser.

There are many regexps which have ‘runaway nature’ on only certain platforms. However, no implementation of a regexp parser that I know of is completely immune to ‘runaway nature’ - some regexp strings just implicitly have it, regardless of implementation.

This is a security leak; causing one of the CPU cores of a webserver to hang for 25 seconds makes it totally trivial to crash the server; this is known as a Denial of Service attack. No data is compromised, but the server just stops working.

There are 2 ways this issue can be fixed, that I can see.

1. Determine if it is possible for a machine to determine in constant time if a certain regexp pattern has ‘runaway nature’, and generate a warning if this is true. This allows web programmers to be warned in advance that they have a security risk.
2. When running a string against a pattern, allow the programmer to specify a ‘limit’. Once the regexp parser backtracks that many times, it just quits and throws an error instead of getting bogged down. By choosing a careful limit, a web programmer can trade off ‘correctness’ against server security. I get the feeling that any input string that causes runaway performance troubles is very likely to be an invalid usecase anyway.

   Unfortunately, neither fix is available as standard solution in any mainstream programming language that I know of.

   I’m not sure how large this problem really is but I can imagine there are lots and lots of webservices out there which can be brought to a grinding halt by feeding it the right (wrong) input.

   ---

   NB: This issue crossed my mind when I crafted the following regexp to check if an input string appears to be a URL. I’m not sure if this regexp has ‘runaway nature’. If you’re a real regexp guru and can figure this out, or if you spot any errors, help me out and let me know in the comments! Thanks a lot!

   • ^([hH][tT][tT][pP][sS]?://)?

   • ((?:[a-zA-Z0-9][a-zA-Z0-9-]*?[a-zA-Z0-9]?)(?:\.[a-zA-Z0-9][a-zA-Z0-9-]*?[a-zA-Z0-9]?)+)
   • (:\d+)?
   • (/[\w/\.;\?:\&=+\$,#]*)?$”

   (1,2,3,4 stands for: protocol, server, port, path string).

Our startup Tipit.to is nearing completion with most of the functionality in place and working. We are in the proces of making the user interface as simple as possible and finishing the implementations of the financials.

In the meantime I am demoing the application to gauge initial reactions. The app itself and the speed of reaction are getting positive reactions. Granted, the concept does need some explanation and that is not likely to change though we are trying to keep stuff as simple as possible.

Demoing for friends has the added advantage of clueing them in on what has been keeping you busy all this time and being valuable practice for when you need to give a demo for real. In the picture I’m demoing to Wimer at Eelke’s graduation party.

No definitive dates available yet but the user interface is near complete and the financials should take another month or so to implement which means we are planning an end of summer launch. Previews coming soon!

(Picture courtesy of Eelke Dekker who graduated this Friday and who is one of the most creative people I know. He should be available for hire.)

If you listened to any of the tales of riches and fame, spun by the golddiggers of the first internet bubble (from 1995ish to 2000), you may have caught one persistent theory:

The micropayment story.

A seminal paper written in 1995, called the Digital Silk Road kicked off a veritable zoo of startups intent on making micropayments work: Facilitating payment on the order of 5 cents to less than a tenth of a cent for near trivial content. Back then blogs weren’t hip yet, so the usual suspects back then were online newspapers and web comics. This list isn’t exhaustive:

FirstVirtual, Cybercoin, Millicent, Digicash, Internet Dollar, Pay2See, BitPass
Source: Clay Shirky

Any of those sound familiar to you?

No, me neither - and I’ve had an interest for small payments for quite a while now. All of them failed. All of them failed quickly.

As you may know, three of the four current fourstarters are involved to some degree or another with a new payment-based startup: Tipit.To. I’ll let the homepage of tipit explain what it’s about.

So, why mess with small payments when they don’t seem to work? I found a few articles which explain the reasoning better than I can - saner souls who have made some very logical arugments as to why the original idea of micropayments can’t work. Fortunately almost none of the arguments actually apply to tipit - on the contrary, most of them actually mean tipit is going to work.

Around 1996, Nick Szabo posted, as far as I know, the first serious argument against micropayments (The Mental Accounting barrier to Micropayments) which argued that there’s a fundamental flaw in micropayment reasoning: Either the payments total up to insignificant amounts, but then there’s not all that much money to be had, or they do tally up to significance, but in that case you can’t claim that the cost, ‘micro’ as it might be, is accepted without much thought. There’s more to it than that, but that rung particularly true for me: even 5 cents is far too much if you’re supposed to pay that much multiple times a day, every day.

Couple of years later, Clay Shirky got in on the micropayments game, torching the viability of the whole idea by highlighting that Free content works already, and works better for handing out fame - which is what bloggers and the like are after far more than money. He argues that, in fame v. fortune, fame wins. And that means micropayments lose. Clay went up against Scott McCloud who locked a comic away behind BitPass, for 25 cents.

Recently, McCloud relented and released that comic for free, causing a revisit from Clay.

Like a breath of fresh air, this post started off a fresh discussion about how to make things better. Nick highlights one form of micropayments that do work: iTunes. Brian Will pointed out his idea for what is essentially tipit, which he described in some detail here, and Nick reviewed the tipit concept!