Created: 2017-01-27 00:25
Updated: 2019-02-18 23:17


Build Status

Proudhon is a collection of classes that parse and generate XML and enable federation in Ruby using the OStatus protocol suite. It provides WebFinger, Atom, ActivityStreams, RSS, PubSubHubbub, Salmon, PortableContacts, GeoRSS and Diaspora compatibility.



gem install proudhon


require 'proudhon'


We'll start with the Webfinger protocol.

The Webfinger protocol provides identities for your users. It is crucial for discovery and federation. The queries use an e-mail like format, so it works in a per-domain basis. For example, Diaspora offers accounts like, which can be easily queried, first by fetching then by fetching the endpoint itself.

Here's the spec:


The /.well-known/host-meta file tell your clients where to find your webfinger endpoint.

We provide a generator:


This command will generate the following xml:

<?xml version="1.0" encoding="UTF-8"?>
<XRD xmlns="">
  <hm:Host xmlns:hm=""></hm:Host>
  <Link type="application/xrd+xml" template="{uri}" rel="lrdd">
    <Title>Resource Descriptor</Title>

The {uri} is mandatory. This is a placeholder for the account name.

You should use the XML to answer a GET query to /.well-known/host-meta. Here's how to do it in Sinatra:

get '/.well-known/host-meta' do

Of course, you can add more link tags by using a block:

puts Proudhon::HostMeta.to_xml('{uri}') { |xml|
  xml.Link(:rel => 'something', :href => '')

Which renders:

<?xml version="1.0" encoding="UTF-8"?>
<XRD xmlns="">
  <hm:Host xmlns:hm=""></hm:Host>
  <Link type="application/xrd+xml" template="{uri}" rel="lrdd">
    <Title>Resource Descriptor</Title>
  <Link href="" rel="something"/>


The host-meta contains a path to your webfinger endpoint, which receives a parameter and returns XML. Here's how to generate the XML:

finger = => { :hcard => "" })

Which renders:

<?xml version="1.0" encoding="UTF-8"?>
<XRD xmlns="">
  <Link href="" rel=""/>

You can follow the example above to serve it in Sinatra:

get '/webfinger/?q=:uri' do |uri|
  user = Users.find_by_uri(uri)
  finger = => { :hcard => "{params[:uri]}" })


Of course, you'll want to return more than just an hCard. Here's a non-extensive list of data you can put on the hash above:

- OStatus specific (To be explained later):
  - :updates_from - Atom feed containing Activities
  - :replies - The user's Salmon endpoint for replies (deprecated but still used by some providers)
  - :mention - The user's Salmon endpoint for mentions (deprecated but still used by some providers)
  - :salmon - The user's Salmon endpoint
  - :magic_key - The user's Magic Key. A public key used to validate the Salmons.

- Not OStatus, but might still be important to the protocol:
  - :atom - Atom feed for subscription
  - :oauth - OAuth endpoint of the user (in case you're using WebFinger as a login strategy)
  - :hcard - HTML page containing an hCard
  - :profile - HTML profile page
  - :poco - HTML page containing PortableContacts
  - :described_by - User's FOAF

- Diaspora-specific
  - :diaspora_key
  - :diaspora_seed
  - :diaspora_guid

The updates_from is mantatory. It provides an Atom Feed that will contain the activies of the user. If you're dealing only with 100% public data, you can implement federation by using only this Atom Feed (coupled with PubSubHubbub).

The replies, mention, salmon and magic_key are, in our case, what makes Salmon work. If you want Salmons to work, you'll need at least a :salmon endpoint and a serialized :magic_key. We'll see about that in a minute.

Querying Webfinger

A remote user can easily be queried:


You'll get an object of the Finger type. It contains some parameters and a hash of links. Webfinger is used most of the time to help validating Salmons (even though you can use the user's Atom Feed for that) and when 'following' a remote user.


Atom feeds are a huge part of OStatus. They are where the bulk of user information is contained. They are so important that some implementations ditch Webfinger and go for an Atom-only implementation. Instead of "following" users by the email-like address, you can optionally "follow" by their URL, and, by reading the <link rel="alternate" type="application/atom+xml" ...>, you get the URL to the user's Atom Feed. However, if you choose to use Webfinger, they should be referenced on the "updates_from" above.

Atom feeds in OStatus are no different than normal Atom Feeds. Refer to the Atom specs and to the Proudhon documentation for more information about which fields to use and such.

Here's how to query Atom feeds:

atom = Proudhon::Atom.from_uri('')

You'll get an Atom object, that can be easily queried. Its structure mirrors the structure of a real Atom feed. Check the documentation to get more information.

=> "ruby - Twitter Search"
=> "Ruby is an amazing language"

And here's how to generate:

atom = => 'My Feed', :id => '1234', :entries => [ => 'Test', :verb => :post) ])

And here's your freshly generated Atom feed (namespaces removed for legibility):

<?xml version="1.0" encoding="UTF-8"?>
<feed ...>
  <title>My Feed</title>

You can serve the generated XML to your users via a feed endpoint. XML constructors on Proudhon follow struct-like semantics on the constructor, so you can use "map" to transforme between a complex database query return and a Proudhon::Atom object, for example. Or you can do things in a more stateful way.

Atom Little-Helpers

Activity Streams, GeoRSS and PortableContacts (POCO) are fields embedded inside Atom documents containing very important semantic metadata concerning the feed entries. PubSubHubbub is (sort of) another addition to Atom that helps distributing feeds between various subscribers without putting the burden on the generator.

Those four tools are also used outside of OStatus. In fact, you can implement federation just with those four, without touching Webfinger and Salmon.

We also included Pingbacks in our implementation, they have a simple implementation and they're already widely used around the web, so it's always a plus.

Activity Streams

Activity Streams are small pieces of information that are coupled with Atom Feeds. They provide standardized verbs for social network communication and represent what your users do. You'll get them automatically if you query a feed with activities.

You can generate them by using the Proudhon::Activity class. They go in the :activity parameter inside each Entry of the Atom Feed.

atom = => 'My Feed', :id => '1234', :entries => [ => 'Test',
  :verb => :post, :activity => => :post, :content => 'Test') ) ])

The result (namespaces removed for legibility):

<?xml version="1.0" encoding="UTF-8"?>
<feed ...>
  <title>My Feed</title>

Notice the activity:verb and activity:object. Those two are the core elements of Activity Streams, but there's even more. You can look up the specification at . Also, check out the Proudhon HTML documentation to see in what places it can be used.


GeoRSS is a universal way to tell a location in an Atom Feed. It is understood by lots of Feed Readers and OStatus implementations. It's pretty easy to use, just a parameter away:

atom = => => '45.256 -71.92' ))

And here's the generated XML (namespaces removed for legibility):

<?xml version="1.0" encoding="UTF-8"?>
<feed ...>
    <georss:point>45.256 -71.92</georss:point>


PortableContacts can be used too, and they go inside Proudhon::Author.

atom = => => 'your name'))

The result:

<?xml version="1.0" encoding="UTF-8"?>
<feed ...>
    <poco:displayName>your name</poco:displayName>

The following fields are available:

  • poco_id
  • poco_display_name
  • poco_name
  • poco_nickname
  • poco_published
  • poco_updated
  • poco_birthday
  • poco_anniversary
  • poco_gender
  • poco_note
  • poco_preferred_username
  • poco_utc_offset
  • poco_connected


In a federated social newtork, you have multiple users in multiple servers, and you have to keep them updated on what the other users are posting. For instance, suppose I just published a nice story on server 1. How does server 2, your subscriber, knows I posted something? Well, the subscriber could "poll" the publisher every N minutes. But this is problematic in two ways: data can appear up to N minutes late on the subscriber, and if you have too many remote users, you'll end up spending way too many network resources.

The other solution is for the publisher to "push" data into subscribers. Much better, but then the network burden is on the publisher. If you have too many subscribers, you'll need massive network resources on the publisher. It would be much better if we had a separated "mailman" to handle that for us.

PubSubHubbub solves that. It uses a third party server, a "hub", if you may, to transmit the data. Whoever generates Atom Feeds can be a producer. Whoever wants to receive notifications is a subscriber.

With Proudhon, you just need a "hub" server. There are many servers, free and commercial. Since the Protocol is quite simple, you can even roll out your own.


In an Atom Feed, you can enable PubSubHubbub by simply the :hub link on your feed:

atom =
atom.links[:hub] = ''

Most readers also relies on the :self link to figure out where the feed will be hosted, so please include it.

atom.links[:self] = ""

After you update a feed, just tell your Hub that it has been updated.

=> ""

That's it. Being a publisher is very easy.


Subscribing is a bit harder, because you need Callbacks to confirm subscriptions and coordinated the messages that arrive.

Just subscribing and unsubscribing is very easy by itself. Here's how it works:

=> ""
=> ""

But notice that you have to pass a parameter called your_callback. It must be an URL that will receive the Atom feeds.

After subscribing or unsubscribing you will to immediately receive a query asking for confirmation in your callback. This is useful to prevent spamming or DDOSing.

The request contains at least three parameters:

  • hub.mode - the command you called: "subscribe" or "unsbuscribe"
  • hub.topic - the URL of the Atom Feed you asked for
  • hub.challenge - the challenge code that must be echoed back

Here's how you would implement a subscriber endpoint in Sinatra:

get "/callback" do
  # Validate those before returning
  topic = params['hub.topic']
  mode = params['hub.mode']

  # If validated, return challenge code to confirm
  if validate_subscription(topic, mode)

After you validate a subscription, data will start being pushed into your callback. You can receive it by using a POST handler. Your data will be in the request body.

In Sinatra, again:

post '/callback' do
  your_data =

That's it. By using Atom Feeds and PubSubHubbub, you can effectively have realtime updates of public data between federated nodes.


"Salmons" are Activities (just like you saw above) from users outside your network that are of interest to your server, like a reply or a post from a remote user that is followed by a local user.

In practice, a Salmon is a signed Atom Entry that's pushed into a remote server. It is mostly used for replies and mentions, and private communication.

Accepting Salmons

You need and endpoint to accept "salmon slaps". You can use the Webfinger method above, but most implementations rely on the Atom Feed. Just use the :salmon link on your feed:

atom = => { :salmon => '' })

Your endpoint is just a POST endpoint with semantics similar to the PubSubHubbub. Here's how you'd do it in Sinatra:

post '/salmon_endpoint' do
  salmon_xml =

Here's how you can process the XML of the Salmon:

salmon =
=> ...

But Salmons rarely carry textual data - they're mostly Atom Feed Entries, so there's also a helper function to convert a Salmon into an Atom Entry:

=> ...

With those two commands you just have to parse the Atom entry and notify users, insert data into your database, etc.


Pingback is as easy as PubSubHubbub. Just pick an entry and call the method.

atom.entry.first.pingback(atom.links[:pingback], "")
=> ""


However, how do you verify the provenance of your salmons? This is normally done via WebFinger or via an third-party Validation Service. It is a bit of a grey area when it comes to OStatus, because there's a lot of confusion on the implementations.

Our tests passes against the data on the specs, but we still can't interop with StatusNet, MiniMe or other OStatus implementations yet.

I strongly suggest that you wait until the code and the specifications gets stable, or help me with my code.

But here's how to verify. It should work between implementations using this library:

finger ='')
magic_key = finger.links[:magic_public_key]
public_key =
=> true

Sending Salmons

You will also need to send new Salmons to other networks. First, you need an Atom Feed entry:

entry = => ',2009:cmt-0.44775718',
  :cntent => 'This is a reply', :title => 'This is a reply',
  :author => => 'Somebody'))

You also need a user-specific private key. Here's how to generate one on-the-fly. Keep in mind that you have to store it in a database!

key = OpenSSL::PKey::RSA::generate(512)

Then, you convert the entry to a Salmon:

salmon = entry.to_salmon

And deliver it:

salmon.deliver('', key)
=> true

That's it.

Diaspora Salmon

Diaspora is an emerging Social Network that uses its own kind of Salmon. It's not compatible with normal Salmons, and doesn't use Atom Feed Entries. The data is cryptographed.

It's a bit more complicated - you need the private key of the user receiving the message to decrypt the message itself.

salmon =, private_key)
=> "Alexander Hamiltom"
=> "acct:tom@localhost"
=> "status_message"
=> {:public=>"false", :raw_message=>"I wanna know", :guid=>"84b5d8cc342062e4", :diaspora_handle=>"tom@localhost", :created_at=>"2011-03-28 16:06:40 UTC"}

The fields you'll receive and the "type" of the message are available on the our HTML documentation.

To create a message you need your private key and the target user's public key:

salmon = = "Alexander Hamiltom"
salmon.uri = "acct:tom@localhost"
salmon.type = "status_message"
salmon.fields = {:public=>"false", :raw_message=>"I wanna know", :guid=>"84b5d8cc342062e4", :diaspora_handle=>"tom@localhost", :created_at=>"2011-03-28 16:06:40 UTC"}
salmon.to_xml(sender_private_key, receiver_public_key)
=> [...]

There you have it. It's basically serialized data going back and forth, but the private/public keys complicate the matter.


RSS feeds are still widely available on the Web, since most readers still accept it. This library includes an implementation.

Proudhon can parse RSS feeds, too:

rss = Proudhon::RSS.from_uri('')
=> ...
=> 'Mashable!'
=> "Will the iPad 3 Have a Futuristic OLED Screen?"

And generate:

rss = => => 'Myself', :items => [ => 'Test') ]))
puts rss.to_xml
=> "<?xml version="1.0" encoding="UTF-8"?>\n<rss version="2.0">\n  <channel>\n    <author>Myself</author>\n    <item>\n      <title>test</title>\n    </item>\n  </channel>\n</rss>\n"
Cookies help us deliver our services. By using our services, you agree to our use of cookies Learn more