The data below is intended as my notes from a reconnaissance mission to see ’what’s out there’. I gathered this data by reading documents, websites, etc. I didn’t run the actual software or look at the source code. So I can only imagine the laughable errors I’ve made. You have been warned.

A set of extensions to JSON/RSS/ATOM/etc. to describe the purpose of an entry such as who posted it, title, if it’s a post or follow or whatever. A useful collection of semantics.

Another set of extensions to RSS/ATOM to provide pub/sub functionality. In general ATOM is meant to be pull based (e.g. people who want updates pull them) but in some cases it can be very useful to have push based updates. PubSubHubbub is a protocol for looking at feeds, finding their hub, sending subscription requests to the hub for the feed and then getting notified whenever the publisher pushes a notification about the feed to the hub.

In theory this is a whole stack of stuff meant to make it easy to find things on the web. Honestly the complexity of this stack is beyond my limited understanding. I could sort of follow Webfinger although its married to DNS and so not terribly useful in a peer to peer context.

A protocol for receiving unsolicited responses to published RSS/ATOM entries. The idea is that someone publishes an article or whatever on ATOM. Someone else reads it and wants to send a response. They can use the Salmon protocol to discover in the ATOM feed where to send responses and the protocol defines how to send the response. It’s up to the original publisher to decide what to do with the comment.

A standard for how to create URIs that point to media resources like pictures or video. When requesting the URI what is returned is a description of the resource with information like its type, version, author, thumbnail, etc. The site that the URL is embedded in can then use this information to decide how to present the URL. For example, they could use the thumbnail link to provide a preview of the picture and then use the full resource pointer to display the resource if the thumbnail is clicked on. The format also provides additional useful information to create a good experience. For example, the URL response contains the size of photos so if a thumbnail is clicked the website embedding the content can re-arrange itself if it wants to create a large enough space.

A standard for advertising a search engine’s capabilities, describing its query URL syntax and how to return search results.

This is part of gnusocial/StatusNet and is a combination of Activity Streams, PubSubHubbub and the Salmon protocol.

A HTTP/JSON based protocol where servers serve up posts which are viewed using Apps. They have discovery, authentication, posting, etc. APIs. I’m not sure why the universe needs a completely new set of such APIs but there is probably history here I don’t know.

An implementation of activity streams that seems to run on JSON rather than ATOM and has its own REST style API rather than use PubSubHubbub and Salmon. You publish content to your feed and pump.io makes it available. Identi.ca is switching over to run on pump.io.

I’m SO confused! So gnusocial says its now the official replacement for StatusNet and that Evan Prodromou is now a consultant to gnusocial. But meanwhile identi.ca is switching over to pump.io. Meanwhile the StatusNet homepage says nothing about gnusocial. So my head hurts. For now I’m going to assume that StatusNet is going away and that gnusocial is its successor. Except near as I can tell there is absolutely no information available as documents, anyway, on gnusocial so the best I can do is summarize StatusNet.

It took me forever to find http://wiki.diasporafoundation.org/Main_Page which seems to be where the actual useful data is on how things work. The core of the Diaspora Project seems to be the federation protocol that instances of Diaspora servers are talking to each other. They use webfinger to find folks which means that folks need DNS address, SSL, etc. From WebFinger one can find the Diaspora pod. This then leads to an activity stream. Pods can sign messages but the trust is at the pod level (which makes sense once you think about it for a second).

This group seems to have three related projects.

An open source project to produce a server for websites that host content similar to Flickr/YouTube. As has already been established I’m slow and was unable to fully understand their website but I’m not sure why this isn’t just a plugin to something like pump.io or gnusocial or Diaspora for Friendica or....

A XMPP based social network that lets anyone run their own node. Note sure of the details really.

A XMPP based social network that lets anyone run their own node. They do have their own HTTP API that seems a lot like what ATOM and related standards do. Not sure why we needed another but there’s probably history there. They also have their own XMPP API.

A XMPP based social network (notice a trend?).

Based on the CouchDB protocol and written in Erlang. I’m not completely sure I understand their model. Is it truly peer to peer or do they need end users to run a dedicated home server (like they show on the front page of their website at the time I write this) as a coordinator? It’s clear they want to run offline which means there is a mobile story here. But I’m just trying to figure out if they are a loosely coupled hub and spoke model or a true peer to peer model. Unfortunately the website has a lot of “More soon here...” so I’m not sure.