RSSSS

Possibly standing for Rather Simple Social Syndication System.

This is something that's been bouncing around in my head for a while. I tried to put together a formal specification when Google Plus died, but didn't quite finish it. So now I'm trying to at least get it written down somewhere. All comments welcome!

When G+ closed, I had a bit of a quandry. All of the people I was following were going to different sites, leaving me with a choice between creating a load of accounts and remembering to check them all, and losing touch with some people I'd like to consider friends. To me, this isn't ideal.

A quick look at social media shows me that there are 3 main types of things to join:

• Monolithic sites (eg. facebook, tumblr, 4chan) have a 'lot' of people on them, but there's one company at the helm. They could close down, or they could decide to block your favourite type of content because it's not popular with advertisers, or they could change the UI in a way which removes features you want.

• Syndication protocols (eg. RSS, Jadis, OpenID) let you follow people on different sites, but functionality is fairly limited. Some big platforms (like Livejournal's successors, and I think Wordpress) use these technologies, but it seems fairly limited. For example, I can use my OpenID to comment on a friend's Dreamwidth posts, and use RSS to subscribe to their feed, but there's no way they can share 'friends only' posts with me. I originally thought of RSSSS as a natural growth of RSS+OpenID, to allow this functionality.

• Federated social networks (eg. Mastodon, Diaspora) Allow multiple sites to work seamlessly as a single social network. When I left G+ I signed up for a couple of these, but didn't like the user interface and couldn't really get used to it. And because they're running the same software, it seemed that all Diaspora pods have the same issues that put me off.

  Around this time last year, I asked if it was possible to join a site running some other software (or roll my own) so that I could still keep in touch with my friends on there (for both Diaspora and Mastodon), and was told "no" by people running their own servers for G+ refugees on those networks. But when I came to write up this page, I found that both networks are part of something called Fediverse, which allows interoperability. If this is as good as it sounds, I might have to give it a try.

Anyway, the idea in my mind was basically to create an open standard along the lines of RSS, which would have optional features allowing sites to look and feel more like the big social networks; Facebook, G+, or whatever. As a growth of RSS, this would mean that implementation would be relatively easy. Developers who have an existing RSS plugin to work with could bolt on the extra features one by one, providing a gradual and low-impact upgrade from RSS to RSSSS.

Are you running RSS or RSSSS?

This specification is supposed to be backwards-compatible with RSSSS. So, when a client is requesting a feed, there should be some way for them to understand that the other end is capable of RSSSS features. This should be transparent, and should not disturb older RSS applications.

Client→Server

The client/reader may indicate to the server that it supports RSSSS in 3 ways. They may use any or all of these, and should try again without them if the request fails. This ensures that even if there is a server somewhere that breaks when it gets an unexpected parameter, it won't break anything.

1. Add an additional parameter to the URL of a request which is believed to be an RSS feed

  rssss=0.1

or

  rssss=auth,sub

The parameter may either be an RSSSS version number, or a list of features. The version is currently 0.1, but should not be necessary in most cases, as the exact capabilities of the client are better conveyed by the features list. If the features list would generate a URL string that is too long, either supply the version number and wait for the server to say which features it supports, or specify others after the important features. If a client specifies the feature all, the server should assume the client supports all features, and the client should silently ignore anything it doesn't understand, or make a more sensible request.

2. If making a POST request for an RSSSS feed (presuming there is any reason to believe the server supports it), add parameters:

  rssssversion=0.1
  rssssfeatures=post,auth

3. Additional HTTP headers (which may be harder to implement on the server side if implementing a RSSSS plugin for some CMS, so should not be relied on)

  X-RSSSS-Support: 0.1
  X-RSSSS-Features: post,sub

Multiple features may be specified on a single comma separated line, or on multiple features lines.

Server→Client

An RSS feed is simple XML, so the client or feed reader should ignore any unexpected elements. Therefore a simple element can be added to an RSSSS feed to indicate to compatible clients/readers that the server is capable of supplying additional data on request.

  <rssss version="0.1" features="auth,sub,post,foo,bar" />

The server should include this element if the client requested RSSSS, and may include it if it is unclear whether the client is expecting RSS or RSSSS.

Features

This RSSSS specification is made up of a number of features that software can choose to implement some or all of. The negotiation in the previous section allows both the client and server to declare a list of which features they support, in order to avoid confusing each other with unexpected parts.

There are a couple of special features, to avoid transmitting a long list with every request:

• all - Assume I support all features; I am able to ignore or sanely deal with any unexpected data as a result.
• advertised - I support all the features you specified in your latest message.
• known - We should cache each other's feature lists if you support this feature; in subsequent exchanges, you may specify just "known" to indicate that your list is unchanged.