We’re standing on the verge of a new era of data ownership and privacy, with decentralisation and cryptography taking center stage on the technical side of things. The series of events that led us to this point has been taking place since long before our suspicions about governments and corporations invading our privacy were confirmed.
In the past decade major players in the “cloud” industry have emerged, and most users trust them—or used to trust them—blindly with their information. If you use the services of one of these companies, and it fails, all your data is gone. We have already seen what happens with one of the most illustrative examples in recent times: the death of Google Reader.
In response to this, former Google Reader users migrated over to new services, which benefitted from its death. These new services are great alternatives and offer some neat APIs, but sadly, we were left with one big problem: inconsistency and fragmentation.
There is no standard protocol for synchronising your RSS+Atom subscriptions across devices—not to mention the great inconsistent mess that RSS already is. Without a consistent way to sync, clients must be specifically built for each of these services, and that’s painful and slow for users and developers alike.
Pond is a new protocol that aims to solve the problems of inconsistency and portability, by defining a set of RESTful HTTP APIs that send and receive data in a standardised format—namely, a set of JSON schemas (and OPML for importing and exporting feed subscriptions). Its main design goals are comfort, ease of use, minimalism and elegance.
Anybody can implement Pond using their technology stack of choice and, as long as any particular implementation satisfies all the API endpoints, anything can be thrown on top of it—for example, the Tent protocol.
There is still much work to be done. I just released version 0.1.0 of the reference implementation, and from this point forward, development of both the specification and the reference implementation will be done in the open. One of the project’s goals—as I already said–is to be very comfortable for developers to use, and the only way to achieve that is with lots of feedback.
If you’d like to contribute, ask questions or just discuss the protocol in general, you are welcome to join the mailing list, by sending an email to email@example.com.
Another great way to contribute, is by downloading the project’s binaries (only OS X and Linux x86-64 are available right now) and using it as much as you can, so I—or any other coder who wants to help out—can iron out any errors. You may submit any bugs you encounter or feature requests you may have to the issue tracker.
The protocol depends on you
For the protocol to succeed and achieve the bright future of maximum portability and developer (and user!) comfort, it has to be adopted by many, many service providers—particularly the big ones. But let’s not be naïve and think that these big services will adopt the protocol right away, just because I say so. We must first prove that it works; we must first start small. So if you have a service or app that runs on RSS+Atom, consider adopting Pond as your synchronisation backend. I, and—I think I can say this confidently—every other RSS+Atom developer and user out there will thank you.