OpenPhoto

Announcing OpenPhoto for iPhone

Thu, 12 Apr 2012 12:38:00 -0700

We can’t solve problems by using the same kind of thinking we used when we created them. — Albert Einstein

It’s been a long time coming but today we’re excited to announce that the OpenPhoto for iPhone app is available in the Apple App Store.

Why is it awesome?
The vision behind The OpenPhoto Project is enormous but we know that we can only achieve it one step at a time. Having your OpenPhoto account in your pocket is one (particularly large) step in achieving our goals.

There’s something powerful in trying to build something for the common good. It means we play by different rules and analyze different metrics. But what’s achieved in the end is magnitudes larger than if you’re focus is elsewhere.

The app you see in the App Store is what we have available on Github. You’re free to fork or modify what we’ve built however you’d like. In fact we encourage it and happily accept pull requests.

But for now you should go download the app and start using it.

Credits
A huge thanks goes out to Tobias Beisel designing the app and Patrick Santana for making it work.

Things are looking different better around here at OpenPhoto....

Tue, 03 Apr 2012 17:02:26 -0700

Things are looking ~~different~~ better around here at OpenPhoto. Sign up for a FREE account!

Web FWD: OpenPhoto Needs You

Fri, 16 Mar 2012 15:46:55 -0700

Web FWD: OpenPhoto Needs You:

webfwd:

Editor’s note: A guest post from Jaisen Mathai, WebFWD fellow and co-founder of the The OpenPhoto Project.

OpenPhoto is entering the Knight News Challenge, an international media innovation contest. The application window closes tomorrow, Saturday, March 17. Please show your support for…

Knight News Challenge: The OpenPhoto Project

Wed, 14 Mar 2012 08:06:59 -0700

Knight News Challenge: The OpenPhoto Project:

Help us continue working on making OpenPhoto awesome by liking, reblogging or commenting on our Knight News Challenge application!

newschallenge:

1. What do you propose to do? [20 words]

Create beautiful decentralized web/mobile applications to publish, organize, share and archive photos using Dropbox, S3, or Box.net.

2. Is anyone doing something like this now and how is your project different? [30 words]

Similar efforts focusing on data…

We're not building a Flickr alternative, that'd be stupid

Thu, 01 Mar 2012 12:20:54 -0800

It’s sometimes difficult to convey the mission of The OpenPhoto Project. Sure we want to liberate people’s photos and give them complete ownership and control of their photos, comments and tags. That leads to the question, “so you’re building an alternative to Flickr?”.

Absolutely not. That’d be stupid.

If you, like us, believe Flickr is fundamentally flawed in how your photos enter and exit their system you too would build something radically different. And this doesn’t just apply to Flickr, it applies to everyone.

So there it is, we’re not building an alternative to Flickr. We’re building an entirely different way to think of how you organize and share your photos. Imagine being able to grant web and mobile applications access to your hard drive, which you ultimately hold the keys to. Now imagine that your hard drive is in the cloud, always available and professionally backed up.

That’s our vision and we hope others adopt it as well.

Patrick Santana: Full time on OpenPhoto - finally

Thu, 01 Mar 2012 08:16:55 -0800

Patrick Santana: Full time on OpenPhoto - finally:

patricksan:

What a such nice day. After a long wait period, today I started to work full time on OpenPhoto. It has been 8 months only contributing on free-time. The project is a great challenge and full of tasks to be done.

On first instance, I’m starting focus on the iPhone app release on App…

Gush shuts down; the case for OpenPhoto

Wed, 15 Feb 2012 01:19:00 -0800

The recent shutdown of Gush reiterates all the reasons we started The OpenPhoto Project. For those unaware of Gush they were a photo service that collected all of your photos from your computer, Facebook and Flickr (source). They’re similar to recent services like Everpix and Snapjoy.

In an email to users, Gush thanks them for testing the service but states they are shutting it down immediately and deleting the photos this week.

Our thesis is that even if a service ceases to exist, you should still retain all of your data. This powerful decoupling of data storage and application logic is what sets OpenPhoto apart from every other photo service and it’s only the beginning.

An open letter to Flickrers who got laid off by Yahoo!

Tue, 31 Jan 2012 11:14:00 -0800

We’re sorry. Getting handed a pink slip is always hard and especially hard if you loved your work. It’s no secret that Flickr is a labor of love for many of the folks working on it.

It’s also true that every closed door leads to unique opportunities so I’d like to extend an invitation to help us build The OpenPhoto Project. We’re over 35 people passionately working to create an amazing photo platform that puts users and community first.

You can find out more information at our website: http://theopenphotoproject.org or get in touch with me (Jaisen Mathai, ex-Yahoo!) personally at jaisen@openphoto.me or @jmathai.

OpenPhoto 1.3.2 release

Mon, 30 Jan 2012 12:32:00 -0800

It’s that time again! The OpenPhoto Team is happy to announce our 1.3.2 release. This release has two themes: make our iPhone app absolutely beautiful and ease the pain for anyone wanting to contribute to the project. We’ve also added Python and Ruby bindings as well as a Wordpress plugin.

Here are the highlights

A fresh look for our iPhone app. We’ve obsessed over every pixel to create an absolutely wonderful iPhone app. If you’re on our TestFlight list then update the app to see the new design. Unfortunately, we’ve reached our limit of test users but the next step is submitting it to the App Store so everyone can use it.
Contributing never seemed so easy. Did you know that over 35 people have contributed to The OpenPhoto Project so far? Now we’ve made it even easier if you were on the fence about helping out! There’s a new contribute section on our website that gives you all the info you need plus ways to get in touch with us. Contribute to The OpenPhoto Project.
Wordpress plugin. Our new Wordpress plugin (wordpress.org, github.com) is the perfect companion for your blog.
Python and Ruby bindings. Our gift to Python and Ruby developers everywhere. Watch or fork openphoto-python or openphoto-ruby and create some apps!
A new AMI. There’s a new AMI available with alpha support for the US-West and EU regions. You can search for openphoto under Amazon’s community AMIs and select the newest one.

NOTE: The US-West and EU AMIs do not use EBS root devices.

The main contributors to this release are:

Patrick Santana, iPhone app (programming)
Tobias Beisel, iPhone app (design)
Randy Hoyt, Wordpress plugin
Randy Jensen, Wordpress plugin
James Walker, Python bindings
Jeff Hammel, Python bindings
Brian Levine, Ruby bindings
Jaisen Mathai, Docs for contributing
Parul Gupta, Docs for contributing
Gareth Greenaway, EC2 AMIs

To keep up on what we’re doing follow us on Twitter, watch us on Github, or send an email to hello@openphoto.me.

Web FWD: It's the Community, Not the Code

Tue, 13 Dec 2011 13:49:12 -0800

Web FWD: It's the Community, Not the Code:

webfwd:

Continuing on our firm belief that it’s not the code, but the people, which drives the success of software, we had a special treat today: WebFWD’s very own Jaisen Mathai, founder of OpenPhoto stepped up as our first team presenter.

Among Jaisen’s observations was just how central APIs can…

Web FWD: The Power of Iteration

Mon, 12 Dec 2011 15:54:27 -0800

Web FWD: The Power of Iteration:

webfwd:

When we created the WebFWD program we were well aware that we’d have to treat WebFWD as a startup in its own right. We knew that we’d have to try things, learn, fail, iterate and build again. And so we have.

We originally started WebFWD with a four-week Bootcamp program, assuming that…

The Internet needs BrowserID - a plea to developers

Thu, 08 Dec 2011 00:36:00 -0800

Identity is a tricky thing. Who are you? What do you identify yourself with? What do you identify yourself as to others? It’s even more complicated on the Internet.

For a long time you’d sign in to every site with a username and password for that site. In essense you had an identity for every site you were a member of. I don’t think that ever made sense to anyone but there wasn’t a trusted identity provider to use, so developers rolled their own.

Many attempts, one winner
Over time we’ve seen numerous attempts at providing identity as a service. Be that a protocol or a proprietary API. Remember OpenID? Yea, that didn’t work out. Everyone agrees that it was too convoluted and confusing for the average user to understand. There has, however, been a winner. They’ve managed to gain the trust of enough users and provide a simple and elegant solution for both developers and users. They’re Facebook.

Let’s rewind
If we want to shape the future we’ve got to understand the past. The Internet is nothing short of amazing. It became this way because it’s built on top of a series of open standards. Protocols like TCP, HTTP, SMTP and POP have fueled over 2 decades of innovation like we’ve never seen. If these protocols were not open then there’s no telling what we would call the Internet today. By that, I don’t mean it may have been better because I believe the chances of that are near zero.

Competition
The story here isn’t about winning as much as it is about competition. That’s because competition breeds choice which breeds more competition and so on. We all remember the days when Internet Explorer had 90% market share and very little competition. I don’t ever want to go back there. Not with something as fundamentally important as the web browser. But I worry that we’re headed right back with something potentially more important: identity.

It’s not that I think the Internet would be better off without Facebook. The second authentication plugin we built for OpenPhoto was Facebook and it ships with every OpenPhoto instance. Facebook simply needs competition from something open. Just as Firefox pried the Internet out of Internet Explorer’s grasp and how Firefox and Chromium are competing with one another today, we need the same for identity.

BrowserID

BrowserID is a decentralized identity system that makes it possible for users to prove ownership of email addresses in a secure manner, without requiring per-site passwords. — Lloyd Hilaiel, Mozilla (source, how BrowserID works)

Facebook Connect won on elegance and simplicity and BrowserID shares the same properties. Users already identify with their email address and they are globally unique. As a user signing into a site with BrowserID it is as simple as entering your email address and password and allowing BrowserID to securely grant the site access to your email address.

Having implemented an early version of BrowserID into OpenPhoto I can say that it’s trivial to implement. In fact, it’s easier than Facebook because one doesn’t have to sign up for an application id. Watch Dan Mills and Ben Adida from Mozilla’s Identity team demo BrowserID below.

Why the onus is on developers
As developers I hope we understand the significance of there being only a single proprietary identity provider. BrowserID is the only solution that’s easy for users to understand, easy for developers to integrate and both open and distributed.

Unfortunately, BrowserID is limited in part by the classic chicken and egg problem. Developers don’t want to integrate it till users are on the system and users never get on the system because developers don’t integrate it.

I don’t believe that has to be the case for BrowserID. It provides a win-win situation for both users and developers. Something OpenID could never deliver on. It’s a very small investment from developers today which will reap significant rewards in the future.

Follow this 3 step guide on implementing BrowserID on Github to get started.

OpenPhoto 1.3.1 release (plus extras)

Tue, 06 Dec 2011 08:47:07 -0800

The OpenPhoto team is excited to announce our 1.3.1 release. In addition to fixing a handful of minor bugs we’ve rebranded, redesigned theopenphotoproject.org and launched the official hosted version of OpenPhoto. As always, you can follow one of our installation guides to get running on your own server.

What’s new in 1.3?

Our new brand and logo. We’ve got a new logo and we love it. It’s a great representation of what OpenPhoto is and which principles guide us: openness, community and freedom.
The OpenPhoto Project website. The newly designed site contains documentation, a community and instructions on getting started.
The hosted version. You’ll need an invite but we’ve made it as easy as possible to get started with OpenPhoto. The hosted version is at openphoto.me and you can see an example at current.openphoto.me.
iPhone app updates. Lots and lots of performance upgrades. The app should be much faster and responsive now. Get on the beta tester list using TestFlight.
A new AMI. The easiest way to get up and running is to boot an instance of the new OpenPhoto AMI. You can search for openphoto under Amazon’s community AMIs and select the newest one.

The main contributors to this release are:

Ali Sabet, Branding & logo
John Fabrizio, Design for The OpenPhoto Project site
Patrick Santana, iPhone updates
Jaisen Mathai, Hosted version
Gareth Greenaway, EC2 AMIs

To keep up on what we’re doing follow us on Twitter, watch us on Github, or send an email to hello@openphoto.me.

OpenPhoto 1.3 release

Tue, 08 Nov 2011 08:38:00 -0800

The OpenPhoto team is excited to announce our 1.3 release. Sign up now if you want to start using the service with your Amazon S3 and SimpleDb accounts. Else follow one of our installation guides.

What’s new in 1.3?

iPhone app updates. The iPhone app now has an upload progress bar. A handful of bugs were also fixed. Get on the beta tester list using TestFlight.
The 5 second upgrade. Upgrading is normally a pain. We spent a majority of this release making it as painless as possible. Anytime you update the source of your OpenPhoto site you’ll be prompted to upgrade by a click of a button.
The kitchen sink gets a dish! Building services on top of OpenPhoto is easy but we’ve got a lot of work to do in guiding you through the process. We’ve got a an OpenPhoto kitchen sink repository that will hold examples of how to do this. The first project in the kitchen sink is a Webhook service that emails an ASCII version of every photo that’s uploaded.
A new AMI. The easiest way to get up and running is to boot an instance of the new OpenPhoto AMI. You can search for openphoto under Amazon’s community AMIs and select the newest one.

The main contributors to this release are:

Patrick Santana, iPhone
Jaisen Mathai, 5 second upgrade
Hub Figuiere, Bugs
Gareth Greenaway, EC2 AMIs

To keep up on what we’re doing follow us on Twitter, watch us on Github, or send an email to hello@openphoto.me.

OpenPhoto's approach to semi-automated software upgrades

Thu, 27 Oct 2011 15:42:00 -0700

As a rule, software systems do not work well until they have been used, and have failed repeatedly, in real applications. — Dave Parnas

Let’s admit it: keeping software up to date is a pain. Not because we don’t have time but because it’s too cumbersome to deal with. It’s a really important problem to solve and we wanted to share our thoughts on it in addition to how we’re making it really easy for you to keep up to date.

What’s in an upgrade?
Upgrades differ between releases. Since we do small incremental releases often it means that some upgrades are as simple as updating your OpenPhoto source files. Other upgrades aren’t so simple. They can require updating other parts of the system such as adding a new table to the database and migrating existing data into it.

100 small updates are easier than 1 giant one
This goes back to our commitment of providing lots of small updates at a regular interval. What we mean by 100 small updates is that in between version 1.0.0 and 1.2.0 there might be 10 smaller versions or 100 smaller versions between 1.0.0 and 2.0.0.

Let’s say you start using OpenPhoto and the latest version is 1.1.2 (our current latest version). No problem, you’ll be set up with the latest and greatest version we have to offer. Then 2 weeks later we release 1.1.3. You’ll see a small message on your settings page that a new version is available. It’s your choice if you want to upgrade or not. Let’s assume you ignore the message and a couple months pass by and at this point we’ve released 1.1.9 and you decide to upgrade to get a new feature you’ve been waiting for.

One man’s “magic” is another man’s engineering. — Robert Heinlein

What we’ll do in this scenario is apply 7 small updates to your site. You don’t need to worry about it since you’ll just be clicking a button. But doing these 7 small updates means 2 things, read on.

Decreasing complexity
Good software takes complex tasks and makes then less complicated. Applying updates in small chunks means that we can roll out new features gradually instead of spending months on it and releasing it as a giant feature. Releasing giant features is nerve wracking for every engineer since it typically touches many parts of the system and any number of things can go wrong.

Bigger isn’t always better. This is especially true in software. — Us

Getting features to users faster
This is such a motivating factor that we’ve spent a lot of time making the upgrade code extremely flexible. It’s what allows us to take a days worth of coding and create a release out of it that anyone can install or upgrade to.

A byproduct of this which we love is that anytime a user starts using OpenPhoto they’re going to get the latest features released within a 2 week window. We’re doing everything we can to bridge the gap between those of us working on OpenPhoto and all of you who are using it.

Here’s to frequent updates!

It's like WordPress for your photos

Mon, 24 Oct 2011 12:09:00 -0700

The OpenPhoto project is quite ambitious but we were searching for a fast and easy way to describe exactly what we’re hoping to achieve. It had to be something many people could relate to and we think the following does a great job:

WordPress for your photos

This fits in line with what we’re doing in numerous ways. Some of what made WordPress successful happen to be what we hope will make OpenPhoto successful as well.

Beautiful themes. WordPress has made it trivial to add a sense of identity to your blogs with a few clicks of the mouse. The first thing people do when they set up WordPress is to select their theme.

Self expression is often underrated and we believe that you want choice in how your photos are displayed too. You don’t have to be a whiz at Photoshop to know what your favorite colors and patterns are. We’ve spent a great deal of time making it easy to build and create themes as well as install them.
Hosted WordPress. Offering a hosted version of the WordPress software enabled an army of people to start blogging who otherwise wouldn’t have been able to. Even the technically minded often sign up at WordPress.com for a blog because it’s easy and fast.

The hosted version of OpenPhoto does the same. A simple signup form and you’re on your way to being up and running. You can still select Dropbox and Amazon S3 if you’d like or postpone that indefinitely and just get started right away.
Ecosystem. There should be studies done on the WordPress ecosystem. We don’t know the number of WordPress theme makers and plugin developers but we know it’s big. It’s been much of the fuel which has led WordPress to become as successful as it is.

We’re focusing obsessively on the ecosystem. This means engaging developers and theme makers early and providing them a platform they love to work on. The result is lots of themes and lots of plugins for every OpenPhoto user.
Run anywhere. You’ll be hard pressed to find a hosting provider that doesn’t support running WordPress. PHP gets a lot of flack but it’s simply the most widely distributed runtime on which to deploy web applications. Beautifully written PHP applications are a win-win.

OpenPhoto can be run anywhere that WordPress can in addition to hosts which don’t even have MySql. We consider this crucial to the adoption of OpenPhoto and have put a lot of time in to keeping dependencies to a minimum.
Open source. It goes without saying that the success of WordPress is largely due to the fact that it’s open source. This gives people the ability to set it up anywhere they want, peace of mind that they can move their content as they like, and that there is a vibrant community behind the project.

Ownership and portability are in the DNA of the OpenPhoto project. Being open source is the first step in that but we took it a step further and allow you to select where all of your data is hosted. It can be the local file system and a MySql database or Amazon S3 and Dropbox.

Beyond these points we’ve got a lot of initiatives in building a best in breed photo sharing and photo management platform. We’d love to get your feedback. You can watch OpenPhoto on Github, follow OpenPhoto on Twitter or email us at hello@openphoto.me.

OpenPhoto 1.2 release

Mon, 17 Oct 2011 22:48:00 -0700

The OpenPhoto team is excited to announce our 1.2 release. Sign up now if you want to start using the service with your Amazon S3 and SimpleDb accounts.

You can find a full list of issues that were closed for this release or read below.

What’s new in 1.2?

iPhone app. Many of you have been testing the iPhone app but in this release we’ve completed the authentication so you can connect the app to your OpenPhoto site. The iPhone app also lets you add filters to your photos. Get on the beta tester list by emailing patrick.santana@openphoto.me.
Dropbox support. You can now have all of your original files copied into your Dropbox account. This includes photos uploaded through the web or using the iPhone application.
A spiffy new theme. We’re including a new theme named Beisel along with the OpenPhoto source. It’s awesome and showcases custom photo sizes really well.
Optimizations for mobile. Both themes are optimized for mobile devices. If you visit your site on an iPhone or Android you’ll see an easy to use version.
Drag ‘n drop uploader. We revamped our uploader by writing it from scratch. This will allow us to continue to make it more awesome with each release.
Webhooks, oh my! Webhooks are probably the coolest thing on the Internet. Now every OpenPhoto installation supports them. This is the first step in creating amazing applications on the OpenPhoto platform. (OpenPhoto Webhook docs).
Permissions and Groups. When you mark a photo as private, it’s now actually be private. You can create groups of email addresses and grant them access to private photos. Users signing in with their email address will be able to see the private photos you’ve given them access to.
API Documentation. Our API is fundamental to everything we do. The entire OpenPhoto site as well as the iPhone app are built on top of the same APIs that’s exposed to the public. Now it’s documented and contains examples. (OpenPhoto API docs)
PHP client library and command line interface. We released an official PHP client library so you can start building applications (other languages coming soon). The client library also contains a command line program. You can upload all photos from a directory using a one line shell script. (OpenPhoto PHP client library)
A new AMI. The easiest way to get up and running is to boot an instance of the new OpenPhoto AMI. You can search for openphoto under Amazon’s community AMIs and select the newest one.
Lots ‘o bugs squashed. They never stood a chance really.

This is a cumulative effort from the entire team dedicating nights and weekends to bring you the absolute best photo sharing and management software in the world. They are:

Patrick Santana, iPhone
Hub Figuiere, MySQL and local file system adapters
Mike Grace, Drag ‘n drop uploader
Preet Jassi, JavaScript framework
Tobias Beisel, The new theme
Gareth Greenaway, EC2 AMIs
Kevin Hornschemeier, Revamped setup flow

To keep up on what we’re doing follow us on Twitter, watch us on Github, or send an email to hello@openphoto.me.

A command line interface for your photos

Thu, 06 Oct 2011 17:28:49 -0700

You’re probably wondering: why? If so you’re wondering the wrong thing. When I’m building features for OpenPhoto I typically test my progress using the command line. Until recently, curl was my best friend while coding (next to vim, of course). Then we added OAuth and general authentication to the API and if you’re familiar with OAuth then you know why curl (without a lot of help) doesn’t work so well.

Turns out that others on the team use the API from the command line to test as well. This is the type of problem engineers love: lots of fun with low value creation.

The good stuff
You can grab the code from the openphoto-php repository on Github. There are instructions in the README of the project but here are some code samples. Below the examples you’ll find some canned secrets to get you started right away. The OpenPhoto API documentation is also on Github (some endpoints not yet documented).

Here’s an example of updating tags on a photo.

./openphoto -h jmathai.openphoto.me -e /photo/7t/update.json -X POST -F ‘tags=testing,more,tavin’
{“message”:”photo 7t updated”,”code”:200,”result”:”7t”}

Canned secrets
You can use the following canned secrets to make calls to jmathai.openphoto.me. Put this in a file and source it prior to using the library and you’ll be all set.

export consumerKey=5c0ce66b069ee1ae7106ab93cdb431
export consumerSecret=42959a6580
export token=d7a4e0acf19c65b7c37e44d86f1316
export tokenSecret=1c281e3367

Building OpenPhoto entirely using our API

Tue, 04 Oct 2011 13:43:00 -0700

You read a lot about building your API first and then your application on top of it. It’s actually quite difficult (translated, requires discipline) unless you start off with the right framework.

What exactly do you mean by API
You ~~can~~ should think of your API as a central access point by which you execute blocks of code or logic and get a response back.

The most obvious example of this sort of API is a RESTful HTTP API. We have an API to get a list of public photos which returns a JSON response. The idea is that anytime we want this same list of photos in our application that we call the API. You’ll end up with a unified interface for your application, AJAX and third party developers and everyone will be happy as a result.

There are a few important points though. You don’t want every single API required by your application to be publicly available. You also don’t want to incur the overhead of an HTTP call to access your own API from your app since you’re already executing server-side code. Let’s cover those next.

External and internal access to your API
This is an important aspect of the framework when it comes to building your API first. Essentially, you’ll wind up having APIs which are public and some which are private. Often times the logic that should be in a private API wind up in a function and called directly. While this typically works you’re no longer going through a central access point to get to that logic and miss out on the benefits of doing so (listed later).

What’s the point of an internal API
An example of an internal API might be a routine to compute the hash of a password. You might not want that to be publicly available (over HTTP) but your application will need to invoke that API. The framework we choose has an API module which lets you define APIs as endpoints and declare if they are public or private. This allows us to define an API such as

/password/hash.json

and not expose it publicly over HTTP. We can still invoke the API to get a response.

$hash = getApi()->invoke(‘/password/hash.json’);

This works out really nice because from our application we can invoke any API and not worry about its visibility since internal and external endpoints are accessible. What happens if you try to access this endpoint over HTTP?

curl “http://mysite.com/password/hash.json”

You’ll get a 404, as you should.

That’s just the basics of the API module we’re using but you get the idea.

Avoiding HTTP calls when you can
A RESTful HTTP API is wonderful but is probably overhead when you’re already executing code on your server. This is a reason why we love the API module in the framework we choose. You can invoke() any API and bypass making a HTTP call. That’s what we did in the example above. Our interface to the API remains identical to if we accessed it over HTTP and we can easily add in a layer to switch to HTTP if we want.

The benefits of relying on your API
Aside from having extremely consistent code and a known path to access logic from within a controller is the benefit you provide developers on your platform. More bugs will be reported faster because not only are you relying on the API but so are your developers. When you fix a bug for yourself it’s also fixing a bug for your developers. It’s a (beautifully) cyclical process.

You can see the documentation of our API. We rely on this exclusively for the OpenPhoto website, iOS and Android app. The User controller is an example of a controller which uses invoke().

Namespacing the web for your photos

Thu, 22 Sep 2011 17:05:00 -0700

We talk a lot about portability. It’s because we believe it’s a crucial part of the Internet. Unfortunately, it’s the opposite for most companies that want to lock you in to their services.

Making URLs portable
It’s not easy to make URLs portable. They consist of several components which are not typically owned by the end user.

First off there’s the domain. Chances are that you don’t own facebook.com which means you can’t take your Facebook profile with you somewhere else.

Second there are these unique IDs. They’re typically long alpha numeric strings which represent some record in some database. The problem is that they’re always global. You just get a random ID that no one else on that system has. The problem here is that if you upload a photo to Flickr it might have an ID of abc123 but that same photo on another service might have an ID of xyz987. These IDs don’t mean anything to the end user.

How does OpenPhoto make URLs portable?
You can’t really talk about portability without talking first about ownership. In order to make URLs portable we need to make it so that you own all the components of your URLs. We’re doing that in two ways.

The primary and most important way is that you have the option of owning the domain that your photos are accessed from. This applies to your public facing website as well as your API. It doesn’t even matter if you run the OpenPhoto software yourself or if you go with the hosted service we’ll be providing in a few months. If you own a domain then point it to your OpenPhoto site and you’re half way there.

The second way is to let you own the IDs of your photos. Because you don’t share a database with anyone else we’re able to provide you with IDs for your photos that are namespaced for you. This means that the first photo you upload will have an ID of a and your 26th photo will have an ID of z. The same applies to every single OpenPhoto user. This becomes extremely important when you switch hosts or decide you want to change from the hosted service to one you install yourself. Your IDs will remain intact.

The combination of these two mean that every URL for your photo will remain the same no matter what OpenPhoto service(s) you use.

These are just two of many steps we’re taking to make sure you own as much of your data as possible. We’d love to hear your thoughts via email or Twitter.