Mobmob is a platform for any developer to easily make mobile device based services. It could be called ‘ning for phones’ if you wanted to mash it up. It’s also very similar to the way Korean and Japanese mobile phone companies run their content businesses, except that it’s open and interoperable.

We provide you with a number of tools, and let you make anything you want.

We think that making a group of services together will be the best thing for the user because it’s too hard to find and learn to use many different mobile services. A clearing house where each application has a similar feeling (even though their functions may be wildly different) will provide a better experience.

For developers, we provide a service platform that serves your needs today, and will grow in the future as different technologies become more common.

After spending time in Japan and looking at the Japanese and Korean mobile services market I was frustrated to learn that there was nothing similar in the US. US carriers want to lock users into their network with incompatible services. This is ridiculous because of Metcalfe's Law, and thankfully impossible because of the open nature of SMS and IP based services in general.

Once Verizon and Cingular gave customers access to packet data, they allowed every amateur developer to make a cross carrier service. Except no one did. Dodgeball is the only successful mobile service anyone knows about, but why?

Part of the reason is that the people who have ideas about what services they want don't have enough experience to build them. Mobmob empowers these new developers to get at app up and running in a few minutes.

Another part of the reason we haven't seen more mobile applications is in Metcalfe's Law for the applications themselves. In the same way that my.yahoo.com becomes more valuable with each Yahoo aquisition (it now has access to Flickr and Upcoming for example), Mobmob becomes much more valuable with each new application.

The phone by itself has such a steep learning curve that most users don't even attempt to use any additional services, but once those services are agreggated in the same place, work similarly, and can talk to each other (in terms of sharing location, sharing friend lists, etc) the ease of use goes way up.

99% of all UbiComp projects die at the end of the semester. Why?

Some of them weren't well loved apps, and their creators let them die, but many just wither without use.

Mobmob is also about momentum. More apps banded together can survive than many apps standing alone.

This is the model that is running successfully in Asia, and we think it will dominate in America too.

Anyone with a cell phone who has ever thought, "gee, I wish my phone could do X." With Mobmob, there's a good chance it already can, and if not, you can make it yourself!

When a user makes an application we give you:

- a subdomain on mobmob.org (i.e. yourapplication.mobmob.org), where you have full ftp access
- an email address at yourapplication@mobmob.org where users send messages to your application by email and SMS
- a mysql database that you have full access to
- a set of libraries that you can use to interact with the main system (to send a message to a user, or check a user’s location, or get their list of friends, etc)
- a testing framework/harness to test new versions of your application as you develop
- if something has gone really wrong you can ‘pause’ your app. it will halt delivery of new messages, and send all the queued ones in a batch when you ‘unpause’
- you can test new code for your app while the app is paused or unpaused
- you can test with a custom built message, or re-run previously sent messages
- a listing and description on the main mobmob.org application list page
- system-wide event broadcasting (a user has checked in, a user has added a friend, etc)
- timed events for applications (basically internal cron, so your app can do it’s own maintenance)

For the show, the user scenario would be explaining this system and how it works and getting feedback of what is needed to make it more appealing to developers. In that case, we would have a flow chart explaining how to sign up and a system diagram showing how all the information flows across phones and servers both external to our application and internally.

It's currently made of PHP, prayer, and bailing wire. It's being rebuilt as a summer project is Ruby on Rails so that all the good debugging parts will work. We could be ready for people to actually make their own applications at the show, but this sounds silly as the won't have their own laptops etc.

Parsing SMS and MMS messages is deceptively simple. Pasing SMS and MMS messages correctly is deceptively difficult!

This type of application is so connected to itself that it requires a fair amount of internal debugging. This is very hard in a language like PHP, which is why we are moving it to a framework like rails.