I wrote most of the initial implementation of rstat.us, but my buddy wilkie wrote most of our ostatus implementation. AMA.
I’d like a concise guide to how the protocols work, and what is required to set them up without any of the details of user registration and such. I don’t want to run an entire site like rstat.us or identi.ca and I don’t want to add a bunch of code to my site when all that is needed is serving up some XML files or whatever it is. I just want to be the authority for status updates for my own, single account.
To host your own e-mail, you need a domain name and an MX record pointing at a server where something is speaking SMTP on port 25. How the mail is routed, stored, and read beyond that point is up to the end-user. Is there something equivalent for OStatus? I just want to know the most basic components needed to implement serving up status updates and receiving them from users I want to follow. Having some kind of way to test interoperability (like subscribing to my updates from identi.ca or something) would be great, too.
I’d like a concise guide to how the protocols work
Specifications are linked.
OStatus: A scheme using a collection of existing standards to provide a microblogging service over a federated network. Describes how to represent feeds, users, etc, at the backend. Client-apis, etc, are out-of-scope.
Related standards follow.
Atom: The syndication format OStatus prefers. XML. Heavily annotated.
ActivityStreams: A standard by which the feeds are annotated. This is what contains the ‘nouns’ and ‘verbs’ that describe how an entry in the feed relates to some event. Like a ‘follow’ verb indicates the entry describes a user that now follows you.
PubSubHubbub (PuSH): The distribution system OStatus uses to multicast. Hubs sit in the middle (or on top) and simply receive a signal that something new appeared at the publisher, and notifies all servers that previously “subscribed.” Subscribers to hubs can be more hubs, publishers can be their own hub, and any other configuration is possible. That is, it can be the naive pub-sub model, or something that can scale.
Salmon: A bypass mechanism around PuSH to notify users of mentions, replies etc that come from sources that user has not subscribed to. Just a piece of XML wrapping some content (An Atom entry typically) directly delivered.
Webfinger: Provides a way to map usernames to an XRD that describes which services that user uses and other related resources (such as their ostatus feed location).
what is required to set them up without any of the details of user registration and such.
All you’d need to do is serve Atom. Then, set up an account on something like superfeedr (or deploy your own small PuSH hub) and point that to your feed url. People on status.net or rstat.us can just type your feed url into their subscribe to modal, and it should work.
If you wanted a name attached (such as email@example.com), you’d set up a webfinger host at that domain and have the XRD point to the feed url. Then people would just type that address to subscribe to it.
Is there an easy one-click install to do just that? No. Unfortunately.
How the mail is routed, stored, and read beyond that point is up to the end-user.
Mhm. Email is a federated system, just like OStatus. If there was an NIH argument against OStatus, it would be that email exists. The mechanisms behind PuSH operate similarly, and share some of the same flaws (such as implied trust among the servers, esp wrt identifying the source of a message and if it is altered)
This is awesome, is there anyway this info could be stored in the project docs somewhere? It helped me make sense of some of the more complicated bits.
Is there something equivalent for OStatus?
It’s built on top of PuSH, so sorta. Pushing to the hub.
I’d like a concise guide to how the protocols work, and what is required to set them up without any of the details of user registration and such.
This is always hard. I’ll think about it and give it a shot. it’s hard to describe something simply while not compromising too much meaning, you know?