今回の記事は後編です。前編はこちら

今回は、エンジニア向けニュースアプリTechFeedの運営や当メディアの編集長も務める白石俊平さんが主催する、Mastodon Tech Night#1に潜入してきました（会場は株式会社リッチメディアさん）。主催の白石さんと、ソーシャルウェブに詳しく当メディアのエキスパートでもあるえーじさんお二人がメインスピーカーとして進行し、３名の方のライトニングトークで締めくくるという内容でした。

「マストドンを支える技術をソーシャルウェブから探る」という副題が付けられた当イベント、エンジニア（特にSNSやソーシャルアプリ開発者）であれば垂涎の「濃い」内容でした。では皆様お楽しみください。

本イベントの会場となった株式会社リッチメディアさん

今回の進行用スライドはこちらです。

今回の記事は後編です。前編はこちら

ソーシャルウェブのプロトコルを探る

白石 では次に、マストドン、というかソーシャルウェブを構成するプロトコルのお話に入りましょうか。

Mastodonを構成する３つのレイヤー（再掲）

えーじ OpenIDについては先ほど説明したので、次はやはりOAuthですね。

サービスをまたいで情報のやり取りを行いたいというニーズに答えるためには、外部サービスのAPI呼び出しを安全に行える必要があります。また、ユーザーが自分に関する情報をどのサービスに、どこまで公開するかと言ったアクセス権を設定したいというニーズも出てきます。 そこで登場したのがOAuthです。OAuthは、Twitterクライアントを作りたいという人たちの間で急速に普及しましたね。

OAuthはもう一般的なので、今はもうそんなことも意識せずに、みなさん利用していますね。「Facebookでログイン」「Twitterでログイン」と言った機能を持つサイトは、みんなOAuthを利用しています。

白石 そうですね。最初期の頃、TwitterのAPIってBasic認証だったので、みんながTwitterのパスワードを外部のサービスに入力していたという(笑) 牧歌的な時代でしたね。

えーじ そうですね(笑)

では次に紹介したいのはWebFingerという技術です。 この技術は、端的にいうと、ユーザーIDが分かれば、そのユーザーに紐付くプロフィールページやWeb APIなどの一覧を取得できるというものです。 「(API)ディスカバリ」の技術と言えますね。

例えば、以下のURLにアクセスしてみて下さい。

https://don.techfeed.io/.well-known/webfinger?resource=shumpei@don.techfeed.io

※ resource=より後には自分のIDを入力して下さい。ドメインはインスタンスに合わせて変えて下さい

えーじ 結果はJSONで返ってきますが、色々と情報がここに詰め込まれています。

※ここに表示しているのは筆者のアカウント情報です

linksの中身を参照すると、APIのエンドポイントURLや、APIの種別などの情報が詰め込まれています。 ユーザーIDさえわかれば、サービス上でそのユーザーに関する情報にアクセスするための様々なエンドポイントが分かっちゃうんですね。これがWebFingerです。

※筆者注: WebFingerは、様々なホストやホスト上のユーザーの情報を取得できるFingerコマンドになぞらえて命名されたと思われる。

links.relの中に、salmonやostatusと言った文字列が見え隠れしていますね。 これが、ソーシャルウェブを構成するプロトコルの名称ですね。

マイクロブログ関連のプロトコルを探る

白石 では次は、マイクロブログ関連の各種プロトコルの話に入りましょうか。 以下が、マストドンのドキュメントから引っ張ってきた、プロトコルの一覧です。 マストドンのコードを深く知るには、これらソーシャルウェブの技術に通じておく必要があります。

マストドン Tech Night#1進行スライドより

白石 それは先程までえーじさんが語っていたソーシャルウェブの世界がその先にあるからなんですね。 そして行き着くところは、マストドンどころか、様々なSNSが自動でディスカバリーし情報連携できる世界。 そんな分散型SNSの世界を実現するための構成要素がこのプロトコルたち、という位置づけです。

じゃあえーじさん、一つ一つを簡単でいいので解説をお願いします。

Atom、ActivityStreams、Atom Threading

えーじ まずは、Atomですね。これはご存じの方も沢山いらっしゃると思います。

これはRSSなどと同じく、フィード情報をXMLで表現する技術で、情報を時系列で発信する場合に適切なフォーマットであるといえます。 サイトの更新情報を発信するのによく使われています。

白石 Atom Publishing Protocolというのもありましたね。 Atom形式で情報をポストしたりできるようにする技術。はてなダイアリーのAPIとかは、AtomPubで構築されていたはずです。

えーじ このAtomを拡張して、サービス上のユーザーアクティビティを表せるようにしたものがActivity Streamsです。 Activity Streamsは、JSON版の仕様も用意されていて、JavaScriptとも相性が良いよう設計されています。

白石 あまり馴染みのない方も多そうですが、SNS上の行動の事を技術的には「アクティビティ」って呼ぶんですよね。 Facebookにも、自分のプロフィールページに「アクティビティログを見る」って機能があります。

えーじ そう、なのでActivity Streamsはそのアクティビティをストリーム形式で参照できる仕様ということです。 一般的なAtomが持つ情報に加えて、写真を取りましたとか、物を買いましたとか、何らかのアクションに紐付いた情報発信ができるのがActivity Streamsの特徴です。

白石 ちなみに、ActivityStreamsといえば、activitystrea.msというドメインだったのを覚えてます。 こういう風に名前とドメインをかぶせるやつ、昔流行りましたよね。

activitystrea.ms

えーじ Web2.0の時代に流行りましたねー(笑)

次はAtom Threadingですが、これはあまり私も詳しくないです。 想像ですが、誰かがポストした時にそれをスレッド化するものなんじゃないかなと思います（※）。

※RFCによると、「Atom内でスレッド状のディスカッションを表現するためのメカニズムである」（This memo presents a mechanism that allows feeds publishers to express threaded discussions within the Atom Syndication Format）だそうです。

OStatus

えーじ 次は、OStatusです。 例えばメンションやフォロー、リプライと言った機能がTwitterにはありますが、そういった機能を異なるサービス間で行えるようにする仕様です。

白石 さっきやったように、マストドン上で @ID@ドメインの形式でメンションとかを行うと、OStatusのプロトコルが動作するというわけですね。

えーじ はい、そうです。

他のユーザーに対してメンションを行うと、まず先ほどお話したWebFingerが動作して、他のインスタンスが持つAPIのエンドポイントを取得します。 その後、実際のAPI呼び出しが行われて処理が実行されるわけですね。

例えばこれは、/api/v1/statuses（ドキュメントへのリンク）というAPIを叩いて、パブリックトゥートの情報を表示したところです。

※記事では適当なトゥートを題材にしています

えーじ mentions や inreply_to 等のキー情報がありますよね。メンションやリプライがあるとここに情報が格納されますが、これがOStatusをはじめとする様々な仕様によって付与された情報なんです。 「プロトコル」と言われるとなんだか仰々しいもののように感じてしまうと思いますが、実際にはこういうシンプルな処理を定義しているだけなんですね。

Salmon

えーじ 次はSalmonです。Salmonは逆流するという意味合いで使われています。鮭なので川を遡上しますよね。別のインスタンスでコメントが付いた場合に、自分のインスタンス上に「戻ってくる」仕組みを提供しています。 ぼく、これ以上のことは知らないんですが、何かご存知ですか？

Salmon Protocol

白石 いやー、知らないですね。 ただ、昔調べたのは覚えてます。2010年くらいに、DaVinciPadっていうサービスを一人で作っていたんですが、このプロトコルを使いたかったんですよね。 メモ＋SNSへのマルチポスト機能があって、そのポストへのリプライをツール上でキャッチアップしたかったんですよ。まぁ、だれも知らないことなんですが(笑)

えーじ あー、DaVinciPadって作ってらっしゃいましたね。なつかしい。

ちなみに、一つ懸念していることがあるんですが、Salmonをはじめこういうプロトコルって基本的に思想が古いんですよね。 XMLベースの仕様が多いことも含め、今のWebに最適化されていないんです。登場から7年も経っているわけなので、大量のトラフィックを捌いていくには、仕様をアップデートしていく必要があるんじゃないかなと考えています。

Portable Contacts

えーじ 次はPortable Contactsですね。これはIdentityに関係するものですが、友達リストを交換するためにフォーマットを合わせるための仕様です。 確か、GoogleにはPortable ContactsのAPIがあって、Gmailのアドレス帳のデータもPortable Contactsの形式で取得できます（残念ながら終了済み）。

白石 なるほど、フォロー／フォロアーのリストとかをやり取りするための汎用的な仕様ですね。 SNSが持つ様々な機能を細切れにして、それぞれ標準化したという感じを受けます。

えーじ その解釈は正しいと思いますよ。汎用的になるように、そして一部だけでも利用できるように、あえて細かく仕様を分けていったという感じじゃないでしょうか。 一つ一つの仕様は小さいのですが、まとめて組み合わせると理路整然としている感じです。

白石 なるほどー。でも、よくこれだけバラバラな、策定している団体や企業も様々な仕様を、うまくつなげることが出来ましたね。 当時、ソーシャルウェブはそれだけのムーブメントだったということですね。

PubSubHubbub、WebFinger、Link-based Resource Descriptor Discovery

えーじ 次は、PubSubHubbubです。 PubSubHubbubはいわゆるリアルタイム通知の仕組みです。サブスクライブしておくと、ハブを介してプッシュ型でメッセージを送ってもらえる。

白石 ちょっと補足すると、RSSなどのフィードって、基本的にはポーリングで取得します。15分に1回とか、30分に1回とか。 でも、更新がなくて空振りすることも多い。それじゃ効率が悪いということで、PubSubHubbubはサイト側からサブスクライバーに向けてプッシュで更新を通知するという仕組みでした。

こないだ、W3Cが急に標準化を進めて、「WebSub」と言う仕様でCandidate Recommendationにしたのはびっくりしました(笑)

WebSub

えーじ 残るはWebFingerとLink-based Resource Descriptor Discoveryですが、WebFingerは先ほどご説明したように、ユーザーやサービスに関する様々な情報を参照するためのプロトコルです。 Link-based Resource Descriptor Discoveryは、サーバ上に置く /.well-known/host-meta というファイルのフォーマットに関する仕様で、WebFingerのURLもこのファイルを参照して取得することができます。

※筆者注: 例えば don.techfeed.ioのhost-metaは https://don.techfeed.io/.well-known/host-metaにアクセスすると参照することができ、その中にWebFingerに関するURLも含まれている。以下がhost-metaファイルの内容。

<?xml version="1.0"?>
<XRD xmlns="http://docs.oasis-open.org/ns/xri/xrd-1.0">
  <Link rel="lrdd" type="application/xrd+xml" template="https://don.techfeed.io/.well-known/webfinger?resource={uri}"/>
</XRD>

マストドンはソーシャルウェブの理想を実現するか？

白石 ソーシャルウェブのプロトコルに関しても一通り眺めたところで、だいぶソーシャルウェブのスタックや、マストドンに関する理解も深まったように思います。 ではそろそろまとめに入りたいと思うんですが、昨今のマストドンブーム、そしてソーシャルウェブを振り返って、思うところがあればお聞かせください。

えーじ そうですね、まずソーシャルウェブの目指すところは、ウェブ上にアイデンティティのレイヤーを築くということ、その上で、サービスをまたいだコミュニケーションを実現するということにあると思います。 マストドンの流行は、そういう世界の実現を後押しするかもしれないと期待しています。

白石 なるほど。ソーシャルウェブの時代はまだまだこれからだ、と。

えーじ まあでも、ソーシャルウェブの理想が完全に実現するか…っていうと道は遠いだろうなあ、と思っているのが正直なところです。

今はとにかく、マストドンが流行ると良いなと思っています。熱狂していた頃から7年も経っているので多少は落ち着いたというか、あんまり純粋に理想を追い求めても、というか…何て言うんだろう。

白石 原理主義？

えーじ ああ、それだ。ソーシャルウェブ原理主義(笑) そういう原理主義的な思想は今は少し収まっていて、とりあえずマストドン流行ればいいや、マストドンが流行れば結果的にソーシャルウェブが流行ることに繋がるし…と、そんな風に感じているというのが正直なところです。

「マストドンの技術を応用して、既存サービスで何ができるか」を考えるのは面白い

白石 ほか、「マストドンの技術を応用して、既存サービスで何ができるか」って話もしたいとおっしゃってましたが、こちらはどうですか？

えーじ そうそう、ソーシャルウェブの技術って、ウェブをベースに考えられているので、既存のサイトとかに組み込むのは実はそれほど難しくないんですよ。 例えばメディアが吐いてるRSSフィードをAtomベースのActivity Streamsに変えたりするとか、そんなちょっとした変更を加えていくだけで、マストドンとコミュニケーションできるようになるかもしれないんです。

白石 なるほど。メディアが1マストドンインスタンス、もしくはマストドンユーザーにもなりうるということですね。

えーじ そうです。白石さんがやってらっしゃるTechFeedとかも、マストドンの技術を取り込む価値はあるんじゃないかと思いますよ。 この会場にいらっしゃる方々も、すでに何らかのサービス開発に取り組んでいらっしゃる方が多いと思いますが、そこにマストドンやソーシャルウェブを組み合わせるとどういうことになるか、ちょっと想像してみるのは面白いと思います。

ちなみに、前にフランスでもマストドンの流行の波が来ていたみたいなのですが、日本はそれの何倍もの大きな波がきているみたいです。 Twitterとかで、英語でこのことをつぶやくと、みんなその理由を知りたがるという状態です。 このままマストドンの活用でも一歩先んじて、マストドン先進国、もっと言えばソーシャルウェブの先進国になれたらいいな…なんてことを思ったりしています。

白石 なるほど、すごく夢のある話ですね…！えーじさん、今日はマストドンとソーシャルウェブについて、とことんまで深く付き合っていただき、ありがとうございました！

ライトニングトーク

えーじさんと白石さんの対談のあとは、ライトニングトークで締めくくりました。

Meganedonやってみた。

meganedonという独自インスタンスを立ち上げてみた話でした。運用する上で重要となるティップスが５分間のLTに濃縮されています。

ソース読む 今日のテーマは Mastodo

マストドンのソースコードを読むためにFreeBSDでインスタンスを立てた話。マストドンのソースコードを追いかけるためノウハウがわかりやすく解説されました。

マイ丼 ５分間　クッキング

TechFeedのCTOである、dsukeさんのLTで、AWS上でTechFeedonを立てた話が紹介されました。ソースコードもGithubで公開中とのこと。

https://github.com/techfeed/techfeedon

最後に

皆さん、いかがだったでしょうか？ 今大人気の分散型SNSマストドンですが、マストドンの裏側に見え隠れしているソーシャルウェブの思想や各種プロトコルについて、垣間見ていただくことは出来たでしょうか？ マストドンは単に流行りのサービス…というわけではないことがご理解いただけたと思います。マストドンに触れる際は、マストドンが実現しようとしている古くて新しいソーシャルウェブの世界観について是非思いを巡らせてみて下さい。

今回の記事は後編です。前編はこちら

今回の記事は前編です。後編はこちら

今回は、エンジニア向けニュースアプリTechFeedの運営や当メディアの編集長も務める白石俊平さんが主催する、Mastodon Tech Night#1に潜入してきました（会場は株式会社リッチメディアさん）。主催の白石さんと、ソーシャルウェブに詳しく当メディアのエキスパートでもあるえーじさんお二人がメインスピーカーとして進行し、３名の方のライトニングトークで締めくくるという内容でした。

「マストドンを支える技術をソーシャルウェブから探る」という副題が付けられた当イベント、エンジニア（特にSNSやソーシャルアプリ開発者）であれば垂涎の「濃い」内容でした。では皆様お楽しみください。

本イベントの会場となった株式会社リッチメディアさん

今回の進行用スライドはこちらです。

今回の記事は前編です。後編はこちら

マストドンのおさらい

白石 皆様こんにちは！本日は「Mastodon Tech Night#1 〜マストドンを支える技術をソーシャルウェブから探る〜」にお越しいただきまして、誠にありがとうございます。

まず最初にお聞きしたいのですが、マストドンのアカウント作った方ってどれくらいいらっしゃいますか？
…ほとんどの方が作ってきてらっしゃいますね。さすが皆さん、予習バッチリですね。

では皆様には「釈迦に説法」になってしまいますが、まだ話題になって間もないサービスでもありますし、マストドンの主要な機能についての軽いおさらいから入りたいと思います。

白石さん

白石 まずは、マストドンのREADME.mdより主要な機能のおさらいです。 開発者自身からすると、マストドンの特徴はこういうところにあるという主張が伺えます。 時間がない中で適当に訳したので、こなれてないのはどうかご容赦ください。

• GNU socialや、あらゆるOStatusプラットフォームと完全な相互運用性がある（Fully interoperable with GNU social and any OStatus platform）
• リアルタイムなタイムライン更新（Real-time timeline updates）
• 連合したスレッド解決（Federated thread resolving）
• 画像やWebMなどのメディアを添付可能（Media attachments like images and WebM）
• OAuth2と直感的なREST API（OAuth2 and a straightforward REST API）
• 長時間かかるタスクのバックグランド実行（Background processing for long-running tasks）
• Dockerでデプロイ可能（Deployable via Docker）

一方、ぼくらユーザーからすると、マストドンの主要な機能って、Twitterと比較するとわかりやすいんじゃないかと思います。 Twitterにも存在する機能としては以下の様なものがありますね。

• ユーザーフォロー
• コミュニケーション（ステータス更新、リプライ、スレッド）
• ハッシュタグ
• タイムラインのリアルタイム更新
• アカウント管理
• OAuthプロバイダー
• WebAPIを利用可能
• …

そして、マストドンならではの機能と言えるのは以下の様なものでしょうか。

• 連合タイムライン
• リモートフォロー
• …

連合タイムラインは、別のマストドンインスタンスからのタイムラインも合わせて表示するもの。リモートフォローは、他ののマストドンインスタンスのユーザーをフォローする機能です。このあたりは、分散型のSNSであるがゆえの機能ですね。

マストドンのコードツリーを眺める

白石 次に、マストドンのGithubリポジトリをざっくり眺めていくとしましょう。

実はぼく、RubyもRailsもほとんど知らないのですが、どうやら色んな人の話を聞く限り、割と素直なRailsアプリになっているみたいです。

マストドンのソースツリー

そこでサービスのコードを読んでみると、すぐに「WebFinger」とか「PubSubHubub」とか、ソーシャルウェブを追いかけていた人にとっては懐かしい単語がたくさん出てくるわけですね。 例えばリモートフォローのコードを読むと、webfingerという単語が出てくる。

どうやら、マストドンはソーシャルウェブと深いつながりがあるようだと。そこでぼく、すぐにえーじさんに連絡して、このイベントの企画を相談したわけです。 では、前置きはここまでにして、ここからはソーシャルウェブの専門家であるえーじさんを交えて、マストドンとソーシャルウェブのつながりを探っていきたいと思います。

マストドンを構成する3つのレイヤー

白石 えーじさん、まずは自己紹介からお願いします。

えーじ えーじです。8年ぐらい前、前職でOpenSocialをはじめとしたソーシャルウェブ技術全般に関わっていました。Social Web Japanというコミュニティも運営していて、ソーシャルウェブに関する勉強会も活発に開催していました。

白石 OpenSocial（※）って言葉を知っている方はどのくらいいますか？ この会場だと半分弱くらいですね。

※OpenSocial…SNSのWeb APIを統一しようとする標準化の動き、及びその仕様。日本でもmixiやGREEを始めとした主要なプラットフォームが対応し、ソーシャルゲーム／ソーシャルアプリの流行に大きく寄与した。

えーじ マストドンって、実は2010年ぐらいに盛り上がったものがベースになっている面があるので、個人的にはタイムトリップしたような感覚ですね(笑)

まずこの図を見て下さい。私は、マストドンは3つのレイヤーから構成されていると捉えています。

マストドン Tech Night#1進行スライドより

この図には出てきていませんが、一番下にはインターネットのレイヤーが存在します。

その上にIdentityというソーシャルウェブを構成するレイヤが重なり、その上にOStatus等のマイクロブログを構成するプロトコルがある。それらの上にマストドンがあるという図です。 逆に言えば、マストドンはOStatus、Identityというレイヤを取り除いてしまうと、ただのTwitterクローンになってしまうと思っています。

白石 なるほど。ソーシャルウェブの専門家から見ると、マストドンはむしろOStatusやIdentityなどの下位レイヤー、つまりソーシャルウェブのスタック上に構成されていることが重要なわけですね。

ソーシャルウェブとは何か？

白石 じゃあ、その「ソーシャルウェブ」って何かということが大事になるわけですが、簡単にご説明願えますか？

えーじ そうですね、じゃあちょっとSNSの歴史も振り返りつつ。

今では、SNSと言えばFacebookやTwitterを思い浮かべると思いますが、2004年くらいから始まった「Web 2.0」と呼ばれていた時代には、Myspaceや、Friendster、mixi、Google buzzなどの様々なサービスが存在していました。 今のような寡占状態じゃなかったんです。

その初期で登場した、当時としては画期的な機能があったんですが、なんだと思いますか？

白石 なんでしょう？SNSが出始めの頃ですよね…？とりあえずめっちゃ楽しかったですね(笑)

えーじ それはそうですけども(笑) 画期的だったっていうのは、招待機能です。招待機能を使ってリアルの知り合いを招き入れる事ができました。

白石 ああそういえば、mixiなんかも最初招待じゃないと登録できませんでしたよね。

えーじ 招待機能っていうのは、リアルな人間同士の関係性をネットに持ち込むってことで、すごく画期的だったんですよね。それはつまり、ネットに人格や人間関係を持ち込むということなんです。

それまでのWebでも、もちろんユーザーはサービスごとにIDを持っていましたが、そのIDは他の人とデータを区別するためのものでしかなかった。SNSではそのIDに、実際のユーザーのプロフィールを紐づけさせた。つまり、リアルワールドの人間とSNS上のアカウントが紐付くことで、ネット上に人間のアイデンティティ（人格）を持ち込んだんですね。

白石 なるほど。それが先ほどのレイヤー構成図で言うところの「Identity」に相当する部分ですね。

えーじ はい、そこの課題意識が、OpenIDなどの認証技術の発展につながりました。ここらへんはあとでまた詳しく述べたいですね。

そして、更にSNSが発展してくると、今度はSNSをまたいで情報をやり取りしたい…というニーズも生まれてきました。 例えば、TwitterからFacebookにつぶやきを送りたいというような。 その象徴的なサービスがFriendFeedでした。

白石 懐かしいですねー。みなさん、FriendFeed覚えてますか？覚えてる人手を上げてください。 …あれ、ほとんどいない(笑)

FriendFeedはFacebookに買収されて、静かに終わってしまったサービスですね。

えーじ はい。これは複数のSNS上での情報を一つにまとめるサービスでした。こういうサービスの登場からもわかる通り、サービス間で情報をやり取りしたいというニーズは確実にあったし、今もある。 そこから発展したのが、先ほどのレイヤー図で言うところの下から二番目の層、「OStatus」などのプロトコルから成るレイヤーです。

白石 なるほど、SNSの発展の歴史とともに、Identityやプロトコルが発展してきて、それがソーシャルウェブと呼ばれるスタックを構成するようになったということですね。 そして、マストドンはそのスタック上に構築されたサービスであると。

マストドン同士が情報をやり取りする世界は、ソーシャルウェブとしてはまだまだ序の口

白石 では、マストドンはソーシャルウェブの一実装だとすると、実は他のサービスとも連携できたりするんでしょうか？

えーじ はい、そのとおりです。その証拠に、マストドンはGNU socialとも互換性があるんです。

白石 あ、それってさっき紹介したマストドンのREADME.mdにも「GNU socialと相互運用性がある」と記載されていましたね。 GNU socialってなんなんですか？

GNU social

えーじ 一言で言うと「ソーシャルウェブ関連仕様の参照実装」ですね。

具体的に言うと、ソーシャルウェブの標準化にあたっては、W3C（※）にあるSocial Web Working Groupというグループが中心となって進めています。 最初は、SNS間の相互運用性を議論する目的で、status.netというサイト上で進められていたんですけどね。

そこで策定が進められた様々な仕様の参照実装 (Reference Implementation)という位置づけのサービス、それがGNU socialなんです。

GNU socialも、マストドンと同じく、自前でインスタンスを立てることもできる。それを使ったインスタンスもいっぱいありました。例えば、quitter。 これ、一昔前のTwitterとUIもそっくりだし、やれることもほぼ一緒です。

Quitter

※ W3C（World Wide Web）…本誌の読者にはいわずもがなではあるが、ウェブの標準化と発展を促進するための標準化団体。

白石 おお、こんなのあったんですね。思想的にはほとんどマストドンと変わらないじゃないですか。

えーじ そうなんです。ただ、サービスとしては動作が遅くて、使うのはかなりストレスフルでしたけどね。 quitterと比較してマストドンが流行ったのは、誰でも簡単にデプロイできる、そして快適でストレスなく利用できることだと思います。

で、quitterはGNU socialのインスタンスなので、マストドンとも繋がります。マストドンのアカウントをフォローしたり、メッセージを送ったりもできるんですよ。

白石 おお、それはすごい。なるほど、マストドン同士がやり取りできるのは当たり前に思えますが、ほかのソーシャルウェブ実装ともやり取りできるのはすごいですね。

えーじ ちなみに、ソーシャルウェブの実装と言えば想い出深いのはGoogle buzzです。Google buzzって覚えていますか？

白石 ぼくは覚えてますが、皆さんどうでしょう？…7名ぐらいしか手が上がりませんね。みんな忘れちゃったんだなあ。

えーじ Google buzzってGmailの一部として登場したし、皆さん一度は目にしたことあると思うんですけどね。 個人的には、Google buzzが出てきたときには大興奮でした。ソーシャルウェブの集大成をGoogleが出した！これはすごい！って。

白石 えーじさんが興奮してたのは、今でもはっきり覚えてます(笑)

えーじ 例えば今でもGoogle buzzが存在したなら、buzzからマストドン上の誰かをフォローしたりできていたかもしれないんです。 それだけじゃなくて、ソーシャルウェブのスタックを実装したどんなサービスとも連携できたはずなんです。

そういう世界を実現したいと思っている人は今でもいて、その人たちがW3C Social Web Working Groupを形作っているというわけです。

白石 じゃあ、今のマストドン同士が情報をやり取りする世界は、ソーシャルウェブとしてはまだまだ序の口で、ソーシャルウェブスタックを実装したサービス同士が自在に情報をやり取りできる世界というのが、ソーシャルウェブの目指す最終地点であり、実現したい世界観ということですね。

アイデンティティ、OpenID、そしてNASCAR問題

白石 では、マストドンで実現されているソーシャルウェブスタックについて、具体的なお話を伺っていきたいと思います。 まずは先ほどのスタックでいう一番下、アイデンティティのところからお聞きしたいです。

Mastodonを構成する３つのレイヤー（再掲）

えーじ まず、ソーシャルウェブでアイデンティティのレイヤーを語るにあたっては、 OpenID 抜きには語れません。

SNSの登場により、Web上で人々がアイデンティティを持つようになりましたが、そのアイデンティティがサービスごとに分断されてしまっていることが問題でした。 例えば、今Twitterを使っているとしましょう。「私はえーじです。」とネット上で表したい時、皆さんはどうしますか？

白石 TwitterのIDをシェアするとか？

えーじ そうですね。Twitterの◯◯、Facebookの◯◯、Google+の◯◯です。というように、各サービスに紐付けざるを得ません。

白石 サービスに関係なく、「私は私です」ということが言えないってことですね。

えーじ そうです。Web上でユニバーサルに「私は私です」と言えないんです。 また、サービスごとに認証情報を作成しなくてはならないのも問題でした。ユーザーとしては、一つのIDで様々なサービスにログインできるほうが便利です。

そこでOpenIDは、URLを利用してユーザーを識別できるようにしたんです。そして、そのURLさえ入力すれば、どんなWebサービスにでもログインできるようにするのが、OpenIDの目標でした。

白石 でもその「URLを入力する」っていうのが、実際にはめんどくさくてあまり流行らなかった印象があります。 ぼくは、OpenIDを利用しているサービスと言えばリクルートさんの「ATND」を思い出すのですが、ATNDにアクセスするとOpenID（一部OAuth）に対応したサービスプロバイダの一覧が出てきて、それを押すといろんなサービスのIDでログインできるという仕組みでした。

ATNDのログイン画面（現在のものです）

あれは、裏ではOpenIDのURLを生成してそこにアクセスしていましたよね。 ATNDにログインした人はたくさんいると思いますので、実際には皆さんOpenIDを使っていたという。

えーじ ATNDはOpenIDの普及に貢献しましたね。 でも、ああやってサービスのロゴを並べるのは、OpenIDの思想からすると問題だったんですよね。 それって、NASCAR問題って言われていたんです。

白石 NASCAR（※）？

えーじ ああやって企業やサービスのロゴを並べるのって、モータースポーツとかで、スポーツカーにべたべたと企業ロゴが貼られているのに似てるからそういう名前になったんです(笑) 今でもTwitterやFacebookのロゴを並べておくのは普通ですけどね。 ユーザーとしては、OpenIDのURLを入力するよりも便利なのですが、もともとのOpenIDの思想…サービスとアイデンティティの分離、からは後退してしまいました。

※NASCAR…Wikipediaによれば、「NASCAR（ナスカー、National Association for Stock Car Auto Racing, 全米自動車競争協会）は、アメリカ合衆国で最大のモータースポーツ統括団体であり（本部はノースカロライナ州シャーロット）、同団体が統括するストックカーレースの総称でもある。」とのこと。

マストドンの画期的なコンセプトの一つは、IDをメアド形式で指せるようにしたこと

えーじ 一方マストドンの素晴らしいところは、IDをメールアドレス形式の username@domain の形にしたところだと思います。 この、馴染み深くて簡潔な形式で、あらゆるマストドンインスタンス上のユーザーを指し示せるようにしたことが、サービス全体の使い勝手を大きく向上させている。

白石 そう言えばマストドンって、その形式のユーザーIDを使って、別のインスタンスのユーザーにメンションってできるんですよね？

えーじ できます、できます。ちょっとやってみましょうか。マストドンはテキストボックスに@id@domainと入力用とすると候補が出てきます。他のインスタンスのユーザでも出てきますね。ちなみに、このオートコンプリートは、マストドンの機能ですね。こういうところが、マストドンの洗練されているところだと思います。

マストドンでは、リモートフォローしたユーザーのIDも自動補完される

白石 なるほど。もしこれがOpenIDそのままだとしたらURL直打ちということになっていたかもしれないし、それだとオートコンプリートさせるっていうのもUI的に少し難しそうです。 IDをメアド形式で指せるようにしたことが、マストドンの画期的なコンセプトの一つということですね。

後編に続きます。