ヤヤカ概説

概要

この文章は ryo33 と tomocchi がYouTubeでLIVE配信を行った内容を、雑に文字に起こして加筆修正したものです。

人物紹介

  • ryo33 Yayakaプロトコルの説明がしたい。
  • tomocchi Yayakaプロトコルを使ってチャットが作りたい。

内容

はじめに

ryo33

Yayaka Protocolで実現する真の分散SNS を見ながらしゃべるので読みながら聞いたほうが良いです。 ただ、注意点としては古いYayakaプロトコルの情報がいくつか含まれます。 とりあえずYayakaプロトコルについて説明していきます。

目的

ryo33

まず、Yayakaプロトコルの目的としては大きく4つあります。 最初は「脱中央集権」で、これはTwitterとかFacebookとかのことを 中央集権として、ああいうのはサービスを管理している人の一存で ユーザーが凍結されたり投稿が消されたりすると楽しくないよねみたいな話で、 権力を分散させましょうよみたいな話です。 つまりサーバーを分散させて動かします。 有名なものでいうと、GNU SocialMastodonも脱中央集権できます。サーバーが分散してるので。 で次が「民主化」。Yayakaプロトコルは民主化もやると。 これはどういうことかというと、脱中央集権といってサーバーを分散させたは いいものの結局それぞれのサーバー管理者が強い。 サーバー管理者がユーザーとか投稿を消せる。 その状況はいま使われている分散SNSでも変わっていないっていうのがあって、 それでYayakaプロトコルは民主化も目指します。 3つ目が「小さなサーバーでのネットワークへの参加」

tomocchi

別に20万30万かけてサーバー運営しなくてもノートパソコン1台で運営したりってことができるみたいな

ryo33

はい、あんまりでっかいサーバー用意しなくても、うん

tomocchi

24時間運営できなくても小さいパソコンがあればみたいな?

ryo33

いや、24時間は24時間がいい。ただ、あんまりたくさん通信しなくていいみたいな。

tomocchi

じゃあheroku (自前でサーバーを用意せずにサービスを運用できるPaaSと呼ばれるサービスの一つ) の無料無料プランにデプロイしちゃっても

ryo33

まあ無料プランでガンガン行けるんじゃないかなみたいな (実際は無料プランではサーバーを常に動かしておくというのができないので難しい)。 で、次4つめが「高い拡張性」とりあえず、あの、どういうものをSNSで共有するかっていうのは ユーザー側がガンガンプロトコルを作って、たとえば、どういう本を読んだかってのを共有するプロトコルとか いまなんていう音楽を聞いているかっていうプロトコルとか、そういうのをガンガン作って、あらゆるものを Yayakaプロトコル上にのせて送ったりしましょうっていう。

tomocchi

みんなで好きなだけ小さなSNSサービスを作ってみましょうみたいな

ryo33

そう。これをベースにあらゆるSNSをつくろうっていう。だからチャットとかも作れるし、なんかこう 普通のTwitter型のSNSとか、

tomocchi

あー例えば投げ銭SNSとか

ryo33

あー投げ銭か。投げ銭は難しそうだな。でも無理ではない。

tomocchi

The SNSというか掲示板とかもできるの?

ryo33

掲示板とかもできる。もちろん。というかんじです。 今の4つ「脱中央集権」「民主化」「小さなサーバーでのネットワークへの参加」「高い拡張性」 という感じです。 まあ、ここらへんまではなるほどって感じ。 で、いま説明したので目的は終了と。

特徴

ryo33

でその目的ためにどういうことをするのかっていうと、 まず、サーバー間を自由に移住できるようにするっていう。 自由にってのは、まぁMastodonとかも自由に移住できるんですけど、 ここで言ってる自由ってのは、あんまり言葉が良くないけど……

tomocchi

同一アカウントで移住できるとか?

ryo33

そう!そうそう、あとは移動したらフォロー関係とか全く別になるのが普通だけど

tomocchi

だけど同じアカウントですべてを引き継いだまま移住できるとか

ryo33

そう、まあ全く痛みのない移住ができると。

tomocchi

あるいみ、炎上した時に逃げたりとかもできたりする諸刃の剣ではありそう。

ryo33

逆に炎上して逃げるんだったら、全くリセットして作ったほうが良いんじゃない?(笑)

tomocchi

ああなるほどね。

ryo33

これはほんとにサーバーが、分散SNSってけっこう管理者がサーバーやめたりとかあるし、 なんか管理者が急に独裁者になって

tomocchi

ああ、嫌な人になったとかね。

ryo33

そうそうそう

tomocchi

急に宗教にハマったとか。

ryo33

(笑)そういうのはないと思うけど。 いや俺も一応宗教っていうのをこのYouTubeチャンネルでやってるので(笑)

tomocchi

なんの宗教?!

ryo33

(笑) いや、まあだから管理者がいじょう?権限を移譲してサーバーの管理権限が移って、 別の人に変わったけどそのひとがやばい独裁者だったみたいなそういうときとか、 サーバーが普通に単に無くなったとか、というときに移住できる。

tomocchi

まあ同じプロトコルだから簡単そう。

ryo33

で、そして、次、それぞれのサーバーが分散SNSの一部分を実装する。 つまり、さっきの「小さなサーバーでネットワークに参加する」ってやつで

tomocchi

てことは、小さなサーバーが大きなサーバーのちからを借りて実装できたりするってこと?

ryo33

そういうことです。 なんか通信をあまりしたくないなら通信は全部あっちに全部任せてUIだけやるとか。

tomocchi

え、おしつけたりできるの?!

ryo33

おしつけられる。

tomocchi

それって管理者のけんかになったりしないのかな。

ryo33

そこはまあ実用しないとわからないところではある。

tomocchi

確かに今は数が少ないから

ryo33

今おれしか使ってない(笑) てか、まだ今新しく制定している途中で実質ない状態。

tomocchi

てか6人も視聴しているのすごくない。

ryo33

いつもは0人か1人くらいなんだけど……

tomocchi

(新しく入ってきた視聴者に対して) 今はYayakaプロトコルっていう、分散SNSが実装できちゃう便利なやつの説明してます。

ryo33

6人目に説明したわけね。 えっと次、サーバー間の通信方法は任意のものが使える。

tomocchi

え、sshとか

ryo33

そうsshだったりとか、WebSocketとかも最近はある。 単純にHTTPSとかでも。 これは、まぁ、なんだろう、例えば通信プロトコルが古くなった時とか

tomocchi

簡単に乗り換えられるんですね。

ryo33

効率がいいやつとか。 で次が、

tomocchi

(音読)追加のプロフィール属性やユーザーによるイベントの種類、コンテンツの種類は上層のプロトコルで定義される。

ryo33

そうこれさっきの「高い拡張性」 たとえばユーザーのユーザーアイコンっていうやつ、あれはYayakaプロトコルでは定義しない。 上のプロトコルで定義する。

tomocchi

ていうことは、Yayakaプロトコルの上にアイコンを決めるための機能を実装してくださいってこと。

ryo33

そう。そのプロトコルを制定してそれにしたがって色んなインスタンス(Yayakaインスタンス: Yayakaプロトコルを実装したサーバーのこと) が実装することによってユーザーアイコンというものを実現する。 でイベントの種類ってのも、イベントってのが、その、ユーザー間で交換されるメッセージみたいなもので、その種類ってのも 上のプロトコルで決まる。

tomocchi

例えばチャットルームを実装するんだったらチャットルームを実装するためのプロトコルをYayakaの上にのせてしまえばいいってこと?

ryo33

そうっすね。でもチャットの場合だったら、Yayakaを生のままで使える、と思う。 ああでも、イベントの種類がテキストイベントが必要

tomocchi

画像イベントとか?

ryo33

そう。まあそんな感じです。

Yayakaサービス

ryo33

まあ今ので特徴の話が終わりで、人数4人と減りましたが、Yayakaサービスという。

tomocchi

(音読)YayakaサービスはIdentityサービス、Repositoryサービス、Social Graphサービス、Presentationサービスの4つがあります。 (音読)ユーザーはIdentityサービスで登録をし、他のサービスを認可 (音読)Repositoryサービスはユーザーによる投稿やお気に入り、リポストなどのイベントを保存します。 (音読)Social Graphサービスはユーザー同士の関係を保持し、イベントを配信します。 (音読)PresentationサービスはウェブフロントエンドやAPIを提供します。 (音読)それぞれのユーザーは複数のRepositoryサービスで投稿し、複数のSocial Graphサービスにイベントを配信し、用途に合わせて複数のPresentationサービスを利用することができます。

ryo33

音読(笑) まあ、Yayakaサービスには4つあってIdentityサービス・Repositoryサービス・Social Graphサービス・Presentationサービスの4つ。 まずIdentityサービスはユーザー情報をおいていたり、登録とかする場所。 で、まあそうっすね。

tomocchi

メール認証とか?

ryo33

そう認証とかするのがIdentityサービス。でさっき言ったユーザーアイコンとか持ってるのもIdentityサービス で、次Repositoryサービスでユーザーのイベントを保存する。さっき言ったユーザー間で交換するもの。 チャットで言ったらテキストとかSNSならダイレクトメッセージとか。Twitterのツイートとかがイベント。 それをRepositoryサービスに保存する。 Repositoryサービスを実装していないサーバーはデータベースとかほぼ必要ない。あまりでかい容量のやつは。

tomocchi

てことはチャットとか特に匿名チャットとかだったら本当に必要ない。

ryo33

いることはいる、ああ、なんだろう、他のサーバーにやってもらう。 で次がSocial Graphサービス。 これがいわゆる人間関係やってるやつ。

tomocchi

フォローフォロワーの関係ってことね

ryo33

そうそれを作るやつソーシャルグラフがフォローグラフをつくって それにしたがってイベントを配信するってのが役割。 で、Presentationサービス。これはなんというか、ユーザーが使うのはコレっていう。 ユーザーはIdentityサービス・Repositoryサービス・Social Graphサービスを直接は使わなくて

tomocchi

間接的に使う。 じゃあRubyでいうコントローラーみたいな、

ryo33

RubyというかRails?

tomocchi

RailsでいうMVCみたいな。

ryo33

そうMVCで言ったらコントローラーなのかもしれません。 コントローラーっていうかビューもやってるけど。 PresentationサービスはUIとかAPIを提供する。

tomocchi

なるほどユーザーがぎりぎり見えるところって感じだね。

ryo33

そう。Yayakaプロトコルは人間は生では使えないじゃん。 それをPresentationサービスがやってくれるし、他のソフトウェアから、 例えばBotから投稿するってなった時はPresentationサービスが提供している APIをつかう。

tomocchi

PresentationサービスのAPIを叩いて残り3つのサービスに接続すると。

ryo33

で、4つあると。 で4つが分かれているとなんで良いのかというと。 まあIdentityサービスは絶対必要。 それはまあ絶対必要じゃん。 で、Repositoryサービスが分かれていると、まあ要するにどこに投稿しても良いわけですよ。

tomocchi

普通だったらIdentityとRepositoryは一緒にされてるけど、 それを別にすることによってどこにでも投稿できるし、 ユーザーに自由な行動を与えてるって感じか。

ryo33

そうそう。Social Graphサービスが分かれているのも似たような理由 フォロー関係を独立させておこうと。 で、さらにSocial Graphサービスって通信がめちゃくちゃ多くなる。

tomocchi

ということはSocial Graphサービスだけを切り捨てて通信速度を早くすることができる。

ryo33

帯域が太くないサーバーを使うんだったらSocial Graphサービスは他のサーバーに頼むっていう。 で、Presentationサービスがわかれているってのは、 これは利用者的には一番嬉しいんじゃないかなってのがあって、 例えば、Twitterって色んなアプリがある感じで、 いろんな見た目とか使い方でひとつのSNSを使えるっていう。

tomocchi

いろんなアプリからPresentationのAPIをたたけるってこと……ではない?

ryo33

そういうことではなくPresentationサービスがいっぱい…… Presentationサービスをみんなが実装する。

tomocchi

みんながPresentationサービスをいじれるのね。UIを。

ryo33

GNU socialってのがあって、あれってMastodonと一応通信できる

tomocchi

そうなんだ。じゃあ上だけ違うってこと。

ryo33

そう見た目が違う。でGNU socialってのは、あとで触ってもらったらわかると思うけど、 ほんと古いUI

tomocchi

昔のTwitterみたいな。

ryo33

あとバグも若干残ってたりする。 でMastodonってUIちゃんとしてるじゃん。 ナウい。

tomocchi

ナウいナウい。

ryo33

で、それ使いたかったら(GNU socialを使っていた人は)Mastodonのどこかのインスタンスに移住するしかないじゃん。いまは。 でもYayakaプロトコルだったら、そういうことが起こった時にユーザーの移動はしないけど、UIだけ別のインスタンスのやつを使う、 ってのができる。

tomocchi

だからいろいろ入れ替えてちぐはぐなSNSが誕生できる可能性があるってことね。 まさにカオス。世紀末。

Amorphosプロトコル

ryo33

で次、「YMPプロトコル」プロトコルってなってますけど、名前変わりました。 「Amorphos」プロトコル (LIVEのチャットにAmorphosと打ちながら)つづりあってるかな……

tomocchi

あってるよ。なんか見た時に綴りちがうなと思った(のを覚えてる)。

ryo33

そう、いちおうギリシャのつづりのはず。

tomocchi

あそうなんだ。なんかむしろそのつづりにしたことによって検索したら上から四番目に出てくるよ。 このプロトコル。

ryo33

で、まあAmorphosプロトコルについての説明。まえはYMPって読んでたんですけど。 えっとこれが、いわゆる複数のサーバーで動く分散アプリケーション間のメッセージングをするプロトコル。 で、さっき任意の通信手段でサーバー間で通信できるって話だったけど、それを実現しているのがこれ。 これは、なんというか、すごい、なにも定義してないかのようなプロトコル。ほぼ何もない。 そこに上層プロトコルとして何かを定義することによって、何かできるようになると。 そこでMessageプロトコルってのがAmorphos上でどういうメッセージをおくるかってのがMessageプロトコル。 つまり、YayakaプロトコルもMessageプロトコルの1つ。

tomocchi

え、そうなの!

ryo33

Amorphosプロトコルの上層プロトコルであるMessageプロトコルの一つがYayakaプロトコルであると で、あともう一種類あってConnectionプロトコル。 これがあの、Amorphosプロトコルを実装したサーバー間でどういうふうに通信を行うかってのを定義するのが Connectionプロトコル。

tomocchi

わかりやすいね。

ryo33

これを定義して実装すれば、任意の通信方法でメッセージを交換するというのが実現できるということになってます。 ちょっと抽象的?

tomocchi

抽象的。 で全部Yayakaがつくりましたということ?

ryo33

え,どゆこと?

tomocchi

全部ryo33がつくりましたということ?

ryo33

ああ、これはそういうことになるかもしれない 遊びで作ってるんで(笑)

処理の流れ

ryo33

次は実際にどんな感じでYayakaプロトコルが動くのか説明しますか。このサイト古くなってるけど。

tomocchi

新しいのは見れないの?

ryo33

まだないね。かなり変わったし。

tomocchi

かなり変わったのか。 まあ、ユーザーがどのサーバーに登録するかはMastdonと同じ感じだし、 Presentationサービスに上でIdentityサービスに接続して登録するってのはわかる。 さっきの説明でそう言ってた。 フォローもソーシャルグラフを叩けばフォロワーの関係がわかるから。 でイベントはどうする?

ryo33

流れとしては、例えばAさんがBさんに何かを送りたい。 ってときにはまず、どっちもIdentityに登録しないといけないどっかの。 もちろん二人共別のサーバーでいい。 で、さらに、Aさんは投稿しないといけないわけだからその場所が必要。 だからRepositoryサービスが必要。 でAさんはそこにPresentationサービスを介して投稿する。 で、そうなるとAさんとBさんにフォロー関係が必要で、

tomocchi

それがSocial Graphサービス。

ryo33

Social Graphサービスではoutboxとinboxをもつことができて、 outboxが差し出す方、送る方、inboxが受け取る方。 日本語でなんて言うんだっけ。訳を忘れた。 で、outboxとinbox間でフォロー関係を結ぶ。 ちょっと説明がこんがらがっているけど、 ユーザーがRepositoryに投稿するときにどこのoutboxに配信するかを選ぶことができる。

tomocchi

outboxを選べるの?

ryo33

そう、outboxは複数持てて、例えばなんか投稿をカテゴリに分けるとか。つかいかたとしては。 ブログとかはココにいれて、雑な情報とかはココに入れてとか情報を分けられる。

tomocchi

タグ付けみたいなのができるということ?

ryo33

タグ付けみたいな使い方はできる。

tomocchi

Slackでいうchannelを量産する感じじゃない?

ryo33

そう、まあ、あと、単にTwitterでアカウントをたくさん持ってるみたいな。

tomocchi

ああそういうことね。

ryo33

それで言ったほうがわかりやすい。 でどこのoutboxに出すかってのを決めて投稿するんだけど、 そうしたらRepositoryがそのSocial Graphに投稿を教える。 でSocial GraphはoutboxをフォローしているBさんのinbox にとうこうを送られて、でBさんのSocial Graphサービスから Bさんのプレゼンテーションサービスにまたその投稿が送られて BさんはAさんの投稿を見ることができると。

tomocchi

途中でかなり介するんだな。

ryo33

けっこう介してる Presentation -> Repository -> Social Graph -> Social Graph -> Presentation

tomocchi

まあそれは予想していた通りという感じだけど。

ryo33

まぁしゃあないっちゃしゃあない。

tomocchi

それぐらいやらないと

ryo33

で、今サービスの登場人物が5かな、Presentation2個とSocial Graph2個とRepository1つ。 これらはもちろん同じサーバー上にあっても良いし、5個とも全部が個々のサーバーにわかれていても動く。

tomocchi

あーそういうことか。ほんとに分散してる。 Mastdonは一応リモートで見れるわけではあるけど、一つで完結してるよねそういうところは。

ryo33

ていう感じです。動作は。

tomocchi

オーケーオーケー何となく理解した。 でも分散すればするほどカオスになるということは分かった。

ryo33

これ、現実的に動くものなのかといわれるとちょっと

tomocchi

バグ出まくるんだろうなー。仕様変更させられるんだろうなー。みたいな。

ryo33

まあ、仕様は真面目に考えているんで。

チャットの作り方

tomocchi

まあ、それを使って動かしてみたくなったなって感じ。

ryo33

おお。それは良かったです。 で、チャットを作りたいと。

tomocchi

チャットルームを作ってみたい。

ryo33

Yayakaプロトコルでチャットを作りたいと。 それはほんとにYayakaプロトコルでTwitter型のミニブログサービスを作るってより、かなり楽。

tomocchi

チャットルームを作るときに登録制にするとか、入るときに名前だけ決めるとか

ryo33

それは確かに難しいかもしれない。

tomocchi

名前を1さん、2さんみたいに勝手につけられて始まる位だったら楽と。

ryo33

そう実際楽。 結局つまり、チャットサービスっていうのはルームをたくさん作る。 ルームごとに別々のoutboxが使われていると。

tomocchi

なるほどね。

ryo33

いやまちがえたinbox。受け取り箱がチャットルームごとにある。 そこをPresentationからみることによってチャットになる。 で、投稿するときには、チャットルームの受け取り箱に フォローしてもらわないといけない。チャットサービスを実装するときにはそれをやんないといけない。

tomocchi

たとえば入る時だけ名前を決めて、退出したら終わるってのはまだ簡単にできる? メアド認証とかなしに。

ryo33

つまりなんか一時的なユーザーアイデンティティを取得するみたいな?

tomocchi

そう一次的にユーザー名とアイコンだけ決めて、入って出たら、終わるみたいな。

ryo33

あーそれね。それできるできる。単にそれって、やり方色々あるけど、一次的にユーザーを作りまくって 退出したら消すっていう方法もある。けど、それって結構めんどくさいことになると思う。

tomocchi

逆に?むしろアカウント作ったほうが楽なのかな?

ryo33

たぶんね投稿用のアカウントをサーバーが1つ作って、元から、で、みんなそれで投稿するという感じじゃない? でもユーザーアイコンを指定したかったら一時的なユーザーが必要か。

tomocchi

あるいみ匿名だけのチャットでそうやってユーザー名とアイコンを決めてしまうチャットルームを種類別で作っても面白そうだけどね。

ryo33

多分プロトコルは作る必要ないと思う。

tomocchi

うえからPresentationで改変すればいい。

ryo33

うん、Presentationで全部実装できるとはず。 まあ、チャットも実装できますと。 ほかは?

tomocchi

ほかは一定時間立ったらけすとか。

ryo33

あーそいうやつね。 それもPresentationでできる。

tomocchi

一定時間で動く時間始動プログラムを作れば簡単に実装できると。

ryo33

そういうかんじですね。

tomocchi

じゃあチャットルームをつくるときの実装期間はどれくらいになると思う?

ryo33

俺だったら……

tomocchi

こっちだったら1ヶ月かかるよなぁ。

ryo33

Yayakaプロトコルを実装したミドルウェアを作りたいってのがあって、 それを使うと多分3時間4時間で作れるんじゃない?

tomocchi

じゃあはやく(ミドルウェアを)作って。(笑)

ryo33

そう早く作りたい。 Dockerで誰でも使えるみたいな、どこでも、どんな環境でも。 Dockerでミドルウェア提供してそれのAPI叩いたらYayakaプロトコルのメッセージが送れるみたいな。 それはしたい。

tomocchi

いま公開されてるYayakaプロトコルでも作れる?

ryo33

つくれる。

tomocchi

それはどのくらいかかる?ミドルウェア使わんかったら。

ryo33

それはねぇ。全部借りればいい。Presentationサービスだけ実装すればいいそれこそ。

tomocchi

例えばチャットルームの箱だけ借りるとか。

ryo33

箱?

tomocchi

既成のチャットサービスの側だけ借りてしまうみたいな。

ryo33

それもできるし、今回チャットサービスはプレゼンテーションサービスだけの話なんで、 そう考えたら結構楽なのかな。

tomocchi

そこに一時的なユーザーを加えてしまうと……

ryo33

いやそれもできる。Presentationだけで。 その一時的なユーザーを作るというのも別のサーバーで作ってしまえばいいって話で。自分のサーバーではなくて。 まあ迷惑かもしれないけど。他のサーバーに。

tomocchi

ああそっかYayaka実装している他のサーバーに接続すればいいんだ。

ryo33

だから投稿とか一時的なユーザーを作成するとかチャットのルームとか全部外のサーバーに置けばいい。

tomocchi

えーーー。そんなのできるの。

ryo33

そう。ひどいとこよ。

tomocchi

つまりryo33の借りてるサーバーを借りて、僕はPresentationだけを実装すればいいと。

ryo33

そう。

tomocchi

ひどい話だけど、とんでもないもの実装したな。

ryo33

実装というか定義しようとしているって感じ。 実用的かはわからない。

tomocchi

まあ実験しないとわからないよね。

ryo33

頑張れば動くか動かないかくらいわかると思うんだけど、 俺はその能力はないかなって感じ。

tomocchi

とりあえずチャットルーム作りたい。

ryo33

今頑張って新Yayakaプロトコル定義してるんで。

tomocchi

そっちを使えばいいってことね。

Yayakaプロトコル状況

tomocchi

Yayakaプロトコルいまどこまで進んでるの?

ryo33

うーん、定義が大体7割ぐらい、あと5時間くらいもらえて集中すれば終わるんじゃないかな。

tomocchi

実際Yayakaでうごいてるサイトみたい。

ryo33

herokuで一応ある。前のYayakaで動いてる奴が。

tomocchi

herokuでYayaka動かせるんだ。

ryo33

3つぐらいサーバーがあってherokuで動いてる。

tomocchi

heroku上で分散させてるんだ。

ryo33

で、これが全部スリープ状態だから起動させたら一応通信して投稿するとかができる。 面倒くさいな。これどうやってやんの?(笑) これグダるな。 これ分散SNSフォーラムで演ったときもグダって「やっぱやめます」っていった。(笑)

tomocchi

えー見せてしまえばよかったのに。

ryo33

あの時はなんとなく空気を悪くするのが嫌だった。

グダって終了。

Written on June 21, 2018