What is the project?
Pump.io is an open-source Node.js-based social network platform. Its provenance is through the same architects as Status.net and Indenti.ca, and is intended to be a modern replacement for the Status.Net platform, and to allow others to create their own networks.
It is, at its essence, a general-purpose network for definition following/follower relationships, and “pumping” activities around the network based on the social graph drawn from those relationships.
It is licensed under the Apache 2.0 license, hosted on GitHub, and has seen sustained commit activity since April 2012, although mainly from one committer.
Who is using it?
Currently, itʼs hard to work out how widely installed it is. The level of blog posts related to pump.io is both low and hobbyist, which is unsurprising considering the nascent nature of the project. With version 0.2.0, the architect claims an improved web front-end, which may speed up adoption.
There is an open demonstration server which shows the software in its current state, and shows its integration with a third party “game”.
It is anticipated by the architect that the pump.io platform will replace the legacy system behind Status.Net, although thereʼs no timescale on this.
Technical overview
It requires node.js 0.8.0 or higher, NPM 1.1.0 or higher and a database server to serve as a persistence store. It uses the node.js databank API for provision of database drivers, for which drivers for memcached, redis, mongodb as well as more basic disk- and memory- based stores. Drivers can be written for more platforms, and, subject to adherence to the API, should integrate.
Changing the storage driver is a case of changing a configuration value. This separation offers an abstraction point for encryption to and from the database, and Pump.io supports SSL by default, further improving its basic security features.
The ActivityStrea.ms API, with its unique key allocation element, is well suited for NoSQL- style data stores (CouchDB, Amazon S3 etc).
The architect runs an active installation, and collates his activity on the project and other areas here:https://e14n.com/evan
Its current Travis-CI build is failing, and has been for a day or two, so the master branch is still very much the bleeding edge of the project.
Due to its current small deployment base, and reliability on a lone developer, itʼs unclear how well-exercised the code is, or how many eyes have been on it. Whilst the platform is open-source, it hasnʼt yet achieved the level of notoriety to reap some of the open benefits yet.
It supports WebSocket, for server-based event notification.
How it federates
Federation is accomplished by applications registering at an (optionally) open endpoint, authorising via OAuth 1.0, and then publishing ActivityStrea.ms objects to a userʼs endpoint.
It appears possible to follow users on other networks, and that actions will be pushed across from one network to another, however the documentation on this is fuzzy, at best.
The discovery elements are strong; using XRD and JRD to discover initial meta-data about a pump.io install, including a client registration endpoint, and WebFinger IDs are supported, allowing targeting of a user on a federated node.
Comparison with other offerings e.g. buddy cloud and status.net?
It is anticipated that pump.io will replace status.net, however thereʼs no timescale put on this, and itʼs clear that pump.io, while a strong start, is taking its time to reach that switchover point. Status.Net is still the more mature, stable option.
Itʼs possible that a pump.io install could federate with a BuddyCloud install – both use the ActivityStrea.ms API – but pump.io is a much more bare-bones plumbing system than BuddyCloud, which has, currently, a much richer feature-set.
Pump.ioʼs main benefit over paid-for offerings such as SocialEngine is that its open-source nature means itʼs free to acquire, and can be openly developed on, with the benefits of contributing back to a nascent proejct.
Its benefits over the more established, PHP-based systems like Oxwall or Status.Net, is the affordances it gains from being written for the Node.js platform, and its targeting of NoSQL data stores. Provision on PaaS systems such as Heroku or AppFog is a simpler affair, and Nodeʼs non-blocking model, combined with JSON ActivityStreams and REST API, make for a product that meshes well with the inherent affordances of the platform itʼs built on.