How to create socnodes?

A SocNode SHOULD publish events in Atom 1.0 format (IDEA: consider required Atom Extensions, eg ActivityStrea.ms)

A SocNode SHOULD publish events to a PubSubHubbub (PSHB) hub, and link to that hub in the Atom feed as defined by the PSHB spec (http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.2.html#discovery)
Using a Hub is what will make socnodes interact in real time!

Main considerations:

Entries published by a socnode MUST have a unique atom ID. And a "source" element. This standard will help you avoid two bugs.

The Ouroboros bug

The Ouroboros or Uroborus is an ancient symbol depicting a serpent or dragon swallowing its own tail and forming a circle. cf. Wikipedia

In socnodes, this bugs occurs when a socnode re-publishes an entry which it actually published first and then recived from another socnode (subscribed to it or to a foaf)

Example:

alpha is subscribed to beta, beta is subscribed to gamma. and gamma is subscribed to alpha or beta or both.
Gamma publishes entry G1, so beta will publish this entry too and so will do alpha.

Now you'd think that gamma will publish G1 again because it recieves it from beta or alpha or both? Yes, that could happen (and it will, actually) if gamma doesn't include a "source" element in its feed for G1.

How to solve this?

Gamma adds a source element to G1 in its feeds, beta and alpha MUST use the same value of this source element in their feeds! When Gamma recieves updates from alpha and beta, it checks the source of the entry, if it comes from the same host where gamma is, it won't republish it again.


The Lernaean Hydra bug

In Greek mythology, the Lernaean Hydra (Greek: ( Λερναία Ὕδρα) was an ancient nameless serpent-like chthonic water beast (as its name evinces) that possessed 9 heads cf. Wikipedia

In socnodes this equals to situations where a single entry is updates many times by one socnode or republished by many other socnodes.

Each socnode MUST have ONE and only one copy of each entry (that is, entries it creates or that it recieves from other socnodes)

Example:

alpha is subscribed to beta and gamma. and beta is subscribed to gamma.
gamma publishes the entry G1. So both beta and alpha should publish it too! (because they're subscribed to gamma) But alpha is subscribed to beta! So it should recieve two identical copies of G1! (one from gamma, and the other from beta)

If alpha publishes blindly each entry it recieves, it will have two copies of G1. Hence the need for "unique identifiers" per entry.

This is actually a standard of Atom feeds. Each entry should have a unique ID.
Mark Pilgrim explains this very well in his Howto Atom-ID article

When a socnode recieves an entry it should look for its ID. If it finds it, it should update the content of its copy of the entry with the recieved data.

As a side benefit (to avoiding the Hydra bug) Updating entries in the network is done almost in real time by all the nodes who have a copy of it.

Hey don't ever be affraid by these mythic monsters! :)
Socnodes are actually not that hard to code. Just think of them as blogs where entries are created by:

  1. Direct input from the user
  2. Post from a Hub
  3. A script that fetches lifestream feeds

Think of Socnodes as a kind of "advanced" blogs and you're fine :)


Comments (a work in progress)

If the SocNode supports comments then it SHOULD supply an Atom Feed for the comments associated with each entry. This feed should be discoverable via a <link rel="replies" /> element as defined in RFC-4685 (TODO: Consider if there is anything else we need to explictly reference form RFC-4685).
The replies Atom feed SHOULD publish events to a PubSubHubbub hub.

If you have ideas, suggestion on how to make this better, or any question about implementing Socnodes in your favorite language, please join the discussion group :)

Is there any known implementation of this?

Yes, there are humble efforts. You can see what's done so far in the implementations page