OStatusの仕様をかいつまんで適当に和訳するよ

OStatus 1.0 Draft 2 http://ostatus.org/sites/default/files/ostatus-1.0-draft-2-specification.html

概要

OStatusは異なるソーシャルネットワーク上のユーザーが、互いにフォローできる仕組みを提供します。
この仕様は関連するいくつかのプロトコル（PubSubHubbub, ActivityStreams, Salmon, Portable Contacts, and Webfinger）からなります。

OStatusは分散更新通知やマイクロブログのための最小の仕様です。
RSSやAtomフィードを配信するサービスであれば、OStatusを利用することができます。
たとえば、旅行サイト、イベント通知サイト、Wiki、写真共有システム、ソーシャルニュースサイト、ソーシャル音楽サイト、podcastサーバー、ブログ、バージョン管理システム、その他の汎用的なソーシャルサービスなど。

1.ライセンス

（原文参照）

2.表記・用法

（原文参照）

3.用語定義

User: サービスの利用者またはbot。
Group: ユーザーの集まり。
Update: Userの状態や行動の変更通知。Userが直接通知するか、またはシステム的に自動生成される。
Feed: 最近のUpdateのリスト。たとえば、UserやGroupのすべてのUpdate、検索条件にマッチするUpdateなど。
Publisher: Updateを通知するUserまたはGroup
Subscriber: Publisherからの通知を受け取るUser。いわゆるFollower。
Follow: PublisherからのUpdateを受け取ること。
Publisher Server: PublisherがUpdateを通知する際に使用するWebサーバー。
Subscriber Server: SubscriberがUpdateを受け取る際に使用するWebサーバー。

4.要件

この仕様で解決しようとする要件・問題領域は以下の通り。

UpdateはUTF-8のプレーンテキスト。
UpdateはHTML。
Updateは複数の添付ファイルを含む。
UpdateはほかのUpdateへの返信になる。（twitterのreply）
UpdateはほかのUpdateのコピーや転送になる。（twitterの公式・非公式retweet）
Updateはトピックに関連付けられる。（twitterのハッシュタグ）
Updateは受信者を指定できる。（twitterのmention）
Updateは位置情報を持てる。
誰でもUpdateに「お気に入り」マークをつけたりはずしたりできる。
Userはユニークな識別情報を持つ。（グローバルユニーク、という意味かと）
Userは名前や所在地、ニックネーム/ユーザー名、略歴、関連するURLなどのプロフィールをもてる。
Userはアバターを設定できる。（プロフィール写真程度の意味っぽい）
SubscriberはPublisherのUpdateをすぐに受け取れる（ほぼリアルタイム、プッシュ通知が欲しい）。
Publisher ServerはあるPublisherのSubscriberのリストを、識別情報とプロフィールも含めて保持できる。
Subscriber ServerはあるSubscriberのPublisherのリストを、識別情報とプロフィールも含めて保持できる。
Publisher ServerはPublisherのUpdateに対する返信のリストをすべて保持できる。
Publisher Serverはコピーや転送されたPublisherのUpdateをすべて保持できる。
Publisher Serverは「お気に入り」マークされたPublisherのUpdateをすべて保持できる。
各サーバーは、Updateに含まれるコンテキストやメタデータを、テキストのパースをすることなく取得できる。（位置情報とかのメタデータをテキストに無理やり埋め込むんじゃなくて、ちゃんとスキーマを定義してメッセージのやり取りをしようということ）
SubscriberはGroupや検索結果、タグに関連するUpdateなど、複数の更新元からのUpdateを受け取れる。（タグ＝twitterのハッシュタグ的なもので、User以外のものもフォローできる、という意味っぽい）

5.対象外

以下のような内容はOStatusでは規定しない。

マイクロブログの文法: ハッシュタグの記法(#)とか、@によるリプライとかは規定しない。そもそもそういったメタデータについて、OStatusではテキストのパースが不要なように、スキーマを規定する。
クライアントAPI: ユーザーとサーバー間のプロトコルやAPIについては規定しない。Webでもメールでもなんでもいい。
プライベートメッセージ: twitterのDMのような1対1のメッセージ送受信については規定しない。
ソーシャルグラフ: User間の関連情報のデータ表現や保持方法については規定しない。ただし、関連情報を検索する際のプロトコルについては規定する。必要であればFOAFかXFNに従う。（曖昧・・・まだ規定してないっぽい。）

6.Updateの表現

Atomの仕様で定義されたActivitiesを使う。Updateはいわゆる"Post"のことで、型としては"Note", "Status", "Comment"となる。各サーバーはこれらの標準の型をサポートすべきで、その他の型のサポートは任意とする。

位置情報はGeoRSSの仕様に沿ってエンコードし、activity内のオブジェクトとして表現される。

添付データはactivityに含まれる形で表現される。

Updateが何かに対するreplyであった場合、Atomの"in-reply-to"の仕様に沿って表現される。

タグ情報はAtomのカテゴリーとして表現される。

OStatusはActivity Streamsに以下の2つの拡張を定義する。

link[@rel=ostatus:attention]/@href
- Updateが特定の誰か宛だった場合は、この形式で対象ユーザーのURIをあらわします。
link[@rel=ostatus:conversation]/@href
- Updateがほかの会話の一部だった場合、この形式で会話のURIをあらわします。

7.Userの表現

ユーザーはURIで識別される。

ユーザーは適切な型のactivityオブジェクトとして表現される。通常は"Person"となる。

追加の情報が無ければ、付加情報の無いActivityデータとして、AtomやRSSフィードの"Post"として表現される。この場合、フィードのauthor要素には<email>か<uri>のいずれか一方を持っている必要がある。

Subscriberは以下の順序でURIを探す。

Activityオブジェクトの<id>エレメント
Atomのauthorの<uri>エレメント
Webfingerのacct: URIとして扱われる、Atomのauthorの<email>エレメント

PublisherはプロフィールのURLをURIとして提供する場合があるが、そのURLが将来的に変わらないものとしなければならない。

UserはHTTP(s)で参照できて、HTMLで表現されていて、そのUserのFeedへのリンクを含んだプロフィールのURLを持つべき。プロフィールのURLは link[@rel=alternate,@type=text/html] の形式でActivityのsubject, actorなどの項目として表現すべき。さもなければ、HTTP(s)のURIで表現すべき。

プロフィール情報を追加するために、authorエレメントやactorエレメントがPortable Contacts形式のデータとして拡張可能になっています。

preferredUsername: ログイン名/ユーザー名
displayName: フルネーム。author/name や actor/title の値。
note: 説明文。
address/formatted: 現在の所在地。
urls[type=home]/value: ユーザーの紹介ページ。Activityのactorエレメントに必要となる link[@rel=alternate,@type=text/html] とは異なる。

Subscriberはmicroformatsなどのほかの形式で提供する場合があるが、非推奨とする。

8.Feedの表現

FeedはActiveStreamsのActivityと同様とする。

すべてのFeedはsubjectエレメントを持つべき。UserのFeedは1つのsubjectかauthorを持つべき。GroupのFeedはそのGroupをあらわす1つのsubjectを持つべき。

すべてのFeedは link[@rel=hub] 形式でPubSubHubbubのエンドポイントURLを持たなければならない。（Updateをを購読するために必要となる）

すべてのFeedは link[@rel=salmon] 形式でSalmonのエンドポイントURLを持つべき。（replyやnotificationを受け取るために必要となる）

9.Updateの配布

Publisher ServerはPubSubHubbub プロトコルにより、更新情報をSubscriberにプッシュ通知する。

複数のSubscriverが同じSubscriber Serverを使って同じPublisherの更新通知を受け取る場合、Subscriber Serverは1つのPubSubHubbub接続を使用するべき。

10.Userへの通知

サーバーはSalmonプロトコルを使って別のUserやGroupに対してイベントを通知する。サーバーはユーザーがPubSubHubbubが使用可能でFeedを受け取れているとは仮定してはいけない。

通知の送信元と送信先はSubscriberとPublisherの関係を持っているとは限らない。

重要なイベントは以下の通り。（細かく書いてあるけど省略）

Attention
Reply
Subscribe
Unsubscribe
Join
Leave
Favorite
Unfavorite
Repeat

11.探索・検索

UserやGroupへのFeedから、それを購読したり通知を送るのに必要な情報を取得できるようにする。プロフィールのデータ、SalmonプロトコルのエンドポイントURL、PubSubHubbubのエンドポイントURLがすべてFeedの中にエンコードされる。

Feedの所在を探索する方法は以下の3通りある。

ユーザーが直接入力する。
ユーザーのXRDファイルに含まれる Link/Rel=http://schemas.google.com/g/2010#updates-from エレメントから。
プロフィールページのHTMLに含まれる link[@rel=alternate,@type=application/atom+xml] 形式のエレメントから。

プロフィールページのURLを取得する方法は以下の2通りある。

ユーザーが直接入力する。
ユーザーのXRDファイルに含まれる Link/Rel=http://schemas.google.com/g/2010#updates-from エレメントから。

ユーザーのXRDファイルを取得する方法は以下の2通りある。

nickname@example.comのようなWebfingerのacct: URIから
プロフィールページのHTTPヘッダから

ユーザーのXRDドキュメントは、そのユーザーのSubscription Serverに対して購読の初期化処理を行うためのURLテンプレートを、http://ostatus.org/schema/1.0/subscribe に添った形でのリンクを提供する場合がある。URLテンプレートはどのアカウントを購読するか、という引数を1つとる。

12.Usage scenarios

12.1.Subscriber ServerからのFeedの取得

SubscriberがSubscriber Serverに取得したいFeedを伝える。（URL, Webfinger account, Feedのリストからの選択）
SubscriberがFeedのURLを見つける。
SubscriberがすでにFeedを取得していたら、6へ。
Subscriber ServerはHTTPでFeedをダウンロードする。
Subscriber ServerはFeedの中からPubSubHubbubのURLを見つける。PubSubHubbubのURLが無ければ、Feedの取得は終了。ポーリングするのはOStatusの範疇じゃない。
Subscriber ServerはPubSubHubbubの仕組みでFeedを取得する。（プッシュ通知を受ける状態にする、ということっぽい。このへんはPub...の仕様を要確認）
Subscriber ServerはSalmonプロトコルでFeedに対するコメントをPublisher Serverにプッシュ通知する。（ここ良くわからない・・・）

12.2.Publisher ServerからのFeedの取得

SubscriberはWebFingerアカウントをPublisher Serverに提供する。（クエリパラメータかPOSTで）
Publisher ServerはWebFingerを通じてそのUserに対するURITemplateを探す。
Publisher ServerはURITemplateをPublisherのFeedのURLで置き換える。
Publisher Serverは先ほど置き換えたURLにリダイレクトさせる。
12.1の1に戻ってFeedの取得を行う。

13.参考資料

[LRDD] Hammer-Lahav, E., “Link-based Resource Descriptor Discovery,” March 2010.
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., “The Atom Syndication Format,” RFC 4287, December 2005 (TXT, HTML, XML).
[RFC4685] Snell, J., “Atom Threading Extensions,” RFC 4685, September 2006 (TXT).
[Webfinger] “the WebFinger protocol.”
[activitiesinatom] Atkins, M., Recordon, D., Messina, C., Keller, M., Steinberg, A., and R. Dolin, “Atom Activity Extensions (Draft),” March 2010.
[activityschema] Atkins, M., Recordon, D., Messina, C., Keller, M., Steinberg, A., and R. Dolin, “Atom Activity Base Schema (Draft),” March 2010.
[georss] “GeoRSS-Simple.”
[poco] Smarr, J., “Portable Contacts 1.0 Draft C,” August 2008.
[push] Fitzpatrick, B., Slatkin, B., and M. Atkins, “PubSubHubbub Core 0.3 -- Working Draft,” February 2010.
[salmon] Panzer, J., “The Salmon Protocol,” February 2010.