オープンコミュニティへのコントリビューション
Interledger Protocol の RFC のお手伝いをしたお話
前書き
みなさん初めまして、Japan Digital Design 業務開発部の中山です。JDD の公式ブログを始めるにあたり、トップバッターでこの記事を書かせて頂いています。
今回は、僭越ながら Interledger Protocol（以下 ILP）という通信プロトコルのドキュメンテーションの一部をお手伝いしたお話をさせて頂きたいと思います。
やった事
簡単にやった事を要約すると、
ILP の RFC として Relationship between Protocols、Dynamic Configuration Protocol の２つのドキュメントを提案し、承認・マージされました
となりますが、以下の要素に分けてお話させて頂ければと思います。
- ILP とは何なのか？
- RFC とは何なのか？
- 提案した２つのドキュメントは何なのか？
加えて、最後に今回この取り組みを行ってよかった事、面白かった事などの所感などもシェアさせて頂ければと思います。
なお、前提知識としては「まぁだいたいエンジニアであれば分かるだろうな」、というくらいを想定しています。全くソフトウェア開発に携わっていない方には多少理解が難しい部分があるかと思いますが、すみませんがこの記事では対象外とさせて下さい。
ILP とは何なのか？
これに関してはここで長々と書くよりも拙著の下記記事を見て頂くのがよいかと思っています（笑）なお、以降の文章はここに書かれている様な事は理解されたものとして書いている部分がありますので、できれば読んで頂きたいなと思います。
ものすごく端折って書くと、自分と相手がどうお金を持っているか（円・ドル・BTC など / 銀行口座・分散管理された台帳など）を気にする事なく、インターネット上で相手に価値（お金）を届けられる様にする通信規格が、ILP です。例えば、自分が銀行口座に円しか持っていなかったとしても、相手にビットコインを届ける事が可能となります。
ILP は W3C の Interledger Payments Community Group のメンバーの手により、開発が進められています。W3C とは World Wide Web Consortium の略で、インターネットに関する仕様の標準化を行う団体です。この中に Interledger Payments（台帳を超えた支払い）に関する仕様策定を行うためのコミュニティがあり、そのメンバーが開発を行っています。なお、このコミュニティはオープンなコミュニティとなっていて、興味のある人なら誰でも参加する事ができます。私も以前から興味があり、個人として参加していました。
RFC とは何なのか？
RFC は意訳すると「公開されたインターネットに関する仕様」という事なのですが、略さずに書くと Request for Comments となります。どうもあまり簡単にイメージはできないですよね。このあたりは歴史的な経緯がある様で、私もリアルタイムで目撃していた訳ではないので資料を見るしかありませんが、こちらの資料（IETF の背景と歴史）が参考になります。RFC の起源は 1968 年に遡る様ですが、私はまだ生まれていません😅
なお、厳密に言うと ILP の RFC は W3C の Interledger Payments Community Group の RFC であり、IETF の RFC ではありません。流れとしては下記の様になる事が、ILP のリポジトリに明記されています。
- Contributor が RFC を提案する（pull-request を送る）
- メンテナー（Core Developer）がレビューをし、RFC 番号を割り当てる
- 問題なければマージされ、この時点で Working Draft となり、以降は改版を行う度にドラフトナンバーがインクリメントされる
- 改版が落ち着いて安定すると、Candidate Specifications となり、Community Group のレポートとして公開される
- 適切であると判断されれば、IETF の Internet Draft として提案される
今回私が提案したドキュメントは、Community Group の Working Draft として認知されました、というものになります。今後必要に応じて、改版されていく事になると思います。
提案した２つのドキュメントは何なのか？
今回提案したドキュメントは２つです。
※厳密に言うと3つなのですが、もう１つはまだレビュー中なので２つと書きました
この２つについて、軽くご紹介できればと思います。
Relationship between Protocols
ILP は複数のプロトコルや仕様からなる、一連の仕様のセット（いわゆるプロトコルスイート）です。これらは個別に先ほどの RFC 番号が振られ、別々に存在しています。しかし、初学者の視点で見ると先ずそれらを俯瞰した全体像が必要であると感じていました。全体としてどう繋がっているのかが分からないと、細かい動作が想像しにくいためです。これは自分自身が初学者で、勉強していく中でそういった資料があればいいのにな、と感じていた事が動機です。
そこで今回、各仕様がどういったものであり、どうお互いに関連しているのかを明らかにするドキュメントを Relationship between Protocols として提案しました。メンテナー達の鋭いインプットをもらいながら修正し、最終的に RFC 番号 33 としてマージされました。
各仕様を全く把握せずに理解するのはそれはそれで難しいのですが、各仕様を見ながらこのドキュメントを見る事で、理解の速度は速くなると信じています。
Dynamic Configuration Protocol
このプロトコルは、ILP を構成する各ノードが動的に通貨コードやアドレスなどの設定を交換するためのものです。詳細を書き出すとキリがありませんので（笑）ここでは割愛しますが、ネットワーク上では補助的なプロトコルになります。
そもそもの発端としては、ILP のリポジトリに「このプロトコルのドキュメントを書いてくれる人おらんかー？」という help wanted の issue が立っていたので協力したかった、という流れです。
背景としては、ILP の RFC はリファレンス実装（ILP を実装したい人が参考にできるサンプル実装）をしながら育てていくというプロセスになっているのですが、いくつかのプロトコルはドキュメント化が追いついていなかったのでこれを整えよう、という動きがあったものです。
実際には既に実装として存在している ilp-connector のソースを解析し、その挙動をドキュメントに起こしたという流れになります。こちらも、実際に ILP のコネクタなどを実装する人が参照できるドキュメントを残したという意味で、一定意味のあるものになったと信じています。
所感
今回、この取り組みを行う上で感じた事、得た知識などを所感としてシェアさせて頂ければと思います。
- RFC で使われる用語は RFC 自体で定義されている
例えば、MUST や MAY などはそれらがどういった意味で使われるべきか、そもそも RFC で定義されています。なるほどな、という感じですね（笑） - オープンなコミュニティはオープン（当たり前）
これは当たり前と言えば当たり前なのですが、オープンなコミュニティは自分から関わりを持つ事で深く関わる事ができます。興味がある技術であれば、RFC やホワイトペーパーをじっくり読み、議論に加わる事でより深く理解する事ができ、技術者としてもより成長できると思います。今回、自分を ILP の世界に引き入れてくれた Stefan Thomas 氏、 Evan Schwartz 氏、 Adrian Hope-Bailie 氏をはじめ、他 Core Developer の皆さん（たくさんいる）に感謝の意をお伝えしたいと思います。 - 会社でこの様な活動ができた事は幸運だった
この様な活動は、直ちに会社の利益に結びつく類のものではありません。もちろん会社は売り上げを出す事で社会的にもその価値を認められ、社員の生活を維持し、ステークホルダーに還元して永続していく事ができるものですし、全く利益を出さない活動をしていく事はなかなか正当化できるものではありません。しかし今回、技術の向上や啓発、将来に向けた技術の礎を築くといった位置付けでこういった活動をさせて頂けた事は大変幸運であったなと思います。今後これを絡めて何かしら具体的な形で会社、社会に貢献できれば、最高だなと思います。 - テクニカルライターになりたいという目標に一歩近づけた
これは完全に個人的な事情なのですが、私は世界的に活躍できるテクニカルライターになりたいと思っています。そのため、この様な実践の機会があった事はとても幸運だったなと感じます。自分ではこれでどうだ！と思っていても、Core Developer 達の鋭いインプットを受ける度に「た、確かに🤔」と思う事ばかりでしたが、それも含め、とてもよい経験になったと思っています。 - 「発明する」側になるべきなのかどうか
ここまで読まれた方はお判りだと思いますが、今回のドキュメントは Core Developer 達が開発した既に概念として存在するものを説明したものです。つまり私が何かを発明した訳ではありません。もちろん、意義のある資料だと考えて書かせて頂いた訳ですが、エンジニアとして「発明する」側に自分が行くべきなのかどうかというのは悩ましいなと思います。T 型人材とか H 型人材とか色々呼ばれますが、要は自分がどういったスペシャリティの人間になるべきなのかという視点で考えていかなければいけないなと思います。結論が出ている訳ではないのですが…😅
終わりに
という訳で、この度の活動についてシェアさせて頂きました。まだまだエンジニアとしてもテクニカルライターとしても成長していきたいと思っています。そして、それを通じて JDD の発展にも寄与していければなと思います。JDD の今後にご期待下さい。
