Holoアプリの壊し方
令和2年9月3日
概要
今回のデベロッパーパルスは様々なアップデートと興味深い情報の宝庫です。まず最初に、Holoの開発チームがHoloPort Nanoのハードウェア上でOSを動作させていることを共有できることを嬉しく思います。
Holo開発チームは現在、ウェブユーザとそれをサポートするHoloPortのすべての可能な障害モードに取り組んでいます。Holoでホストされたアプリがどのように動作するかに興味がある方には、興味深い一読になるかもしれません。
Juntoの創設者であるEric Yang氏は、Holochainの開発者エコシステムをサポートし、ハイブリッドなデプロイ技術を開拓するためのプロジェクトの計画の一部を共有しています。
トピック
- HoloPort Nanoは最新のOSで動作するようになりました
- HoloでホストされたhAppの様々な障害モードを見てみましょう
- Juntoの進捗状況とHolochain開発者エコシステムへの貢献
HoloPort Nanoは最新のOSで動作するようになりました
HoloPort Nanoを注文された方は、次のアップデートを待ち望んでいることでしょう。5月には、ハードウェアメーカーへ提供したOSイメージがトラブルを抱えていたことが大きな障害となっており、まだ作業が続いていることをお伝えしましたが、先週良いニュースがありました。HoloPort OSがNanoで動作するようになったのです! これは、メーカーに新しいマスターイメージをすぐに提供できることを意味します。
ここでは、HoloPort プロダクトリードのAlastair氏が HoloPort Nanoを起動して登録している様子を動画で紹介します。
<iframe width=”671″ height=”377″ src=”https://www.youtube.com/embed/ctlShbwKQAw” frameborder=”0″ allow=”accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture” allowfullscreen></iframe>
HoloでホストされたhAppの様々な障害モードを見てみましょう
親愛なる読者の皆さん、なぜ自分の製品がどのように壊れるかについて自発的に話をするのかと聞かれるかもしれませんが、実際のところ、コンピュータは壊すのが得意なのです。特にネットワーク化されたコンピュータでは、様々な障害モードを予測して処理しないスタックはトラブルを招くことになります。
前回のデベロッパーパルスでは、HoloがホストするhAppで確認した障害モードのいくつかの図を共有しましたが、詳しく説明はしませんでした。今、Holoの開発チームがこの問題に取り組んでいるので、もっと深く掘り下げてみようと思います。何がうまくいかないのかを説明することで、Holoホスティングの仕組みに光を当てることができればと思っています。
インターネット上でマーフィーの法則に触れるという異常な事態に陥ってしまったAliceを例えにして説明していきます。
Aliceは、彼女の街専用の新しいライドシェアのウェブサイトについて聞き、それを試してみたいと思いました。彼女はウェブサイト https://mycityrides.app (本当のURLではないです)に行き、彼女はHolochainと独立したホスティングプロバイダのネットワークの協力を介して自分のデータへの主権のほんの少しを確保しようとしていることにまだ気づいていません。
アリスがそのURLを入力すると、従来の中央集権型サーバーがアプリのフロントエンド用のすべての静的アセットを提供します。
ダウンロードしたアセットの1つは、小さなiframeを作成するHolo Web SDKです。このiframeはChaperoneをロードし、Aliceのブラウザがホストに接続することを可能にする暗号化された優れたツールです。(このiframeのコンテンツはHoloのサーバーでホストされています。これは重要なことなので後程説明します)
一度Chaperoneがロードされると、ChaperoneスクリプトはHoloリゾルバサービスとユーザーの割り当てられたホストに接続し、ブラウザのウィンドウ間メッセージングチャンネルを使用して、それらのサービスとUI間の通信を仲介します。このチャネルにより、UI はChaperoneの内部情報を漏らすことなく、Chaperoneとのインターフェースを行うことができます (ブラウザの同一オリジンポリシーがこれを処理します)
Chaperoneは、以下の障害ケースのほとんどを、独自のUIを表示するか、自分自身で解決しようとすることで、優雅に処理しようとします。私たちは、UI開発者が処理しなければならないエラーメッセージをできるだけ少なくしたいと考えています。最終的には、UIに戻されるエラーは、バックエンドのDNA(Holoがホストしている部分)によって生成されたエラーのみになると考えています。その時点では、UI開発者の好きなようにエラーを処理することができます。
Chaperoneがアプリユーザーに直接エラー表示をする必要がある場合は(サインアップ/サインインダイアログを表示したり、回復不可能な障害のエラーメッセージを表示したりする場合)、Chaperoneは自分自身を可視化し、フルスクリーンに拡大して、UIに画面を表示します。
ドメイン未登録
AliceがURLを間違って入力して、偽のライドシェアサイトにたどり着いたとしましょう。Chaperoneのiframeがロードされると、それをロードしたUIのドメイン名をHoloリゾルバサービスに尋ねます。そのドメインが見つからない場合は、エラーメッセージが表示されます。おそらくフィッシングサイトはこのエラーを隠そうとしますが、この時点では先に進めないので問題にはなりません。これでChaperoneは役目を終えたことになります。
(Holo自体がChaperoneのiframeのコンテンツをホストすることが重要な理由その1です。ドメインはiframeのリファラープロパティから抽出され、UIではなくブラウザによって制御されるため、なりすましは不可能です。また、ブラウザのオリジン間リソース共有メカニズムのおかげで、リソルバーサービスに偽フィッシングChaperoneからのリクエストを拒否する機会を与えることができます)。
利用可能なホストがない
AliceはURLを正しく取得し、Chaperoneはレジストリ用にhAppの詳細をロードします。ここで、Holoリゾルバサービスに、hAppの詳細をホストしていると主張するいくつかのホストを尋ねます。しかしここで、リゾルバはホストを見つけられなかっとします。(もしかしたら奇妙な偶然の一致で、ホストがすべて同時にオフラインになってしまったのかもしれません。可能性は低いですが可能ではあるので、それを想定しておく必要があります)。この場合、Chaperoneはエラーメッセージを表示します。
ホストに接続できない
アリスはライドシェア会社に文句を言い、会社側は問題を修正してくれました。Holoリゾルバサービスは、いくつかのランダムなホストのアドレスを返します。Chaperoneは最初のホストを選び、接続を確立しようとします。このホストがオフラインの場合、Chaperoneはスマートに、リストにある次のホストと接続を試みます。
代替ホストがない
しかし、例えばインターネットの不具合があり、どのホストもオンラインになっていなかったとします。この場合、Chaperoneはエラーメッセージを表示しなければなりません。
Aliceはついにアプリにアクセス
Aliceはイライラしながらも、この新しいサービスにチャンスを与えたいと思っていた。後日、別の怒りのメールがAliceから届き、会社はライドシェアアプリのDNAのためにさらに多くのホストをプロビジョニングすることに成功しました。
アリスはもう一度試してみると、「匿名」インスタンスを実行しているホストに接続されています。これは、hAppの開発者が匿名ユーザー(人間と検索エンジンのクローラーの両方)に、実際にデータを作成させることなく、アプリのデータへの適切なアクセス量を与えることができる特殊なケースです。
アリスはこのアプリに価値がありそうだと思ったので、「乗車予約」ボタンをクリックします。これにより、バックエンドのDNAへの関数呼び出しがトリガーされます。UIはWeb SDKを呼び出し、Web SDKはChaperoneを呼び出し、Chaperoneはホストを呼び出します。しかし、ホストは「これは単なる匿名のアプリのインスタンスであり、この関数呼び出しには実際のユーザーが必要です」と言います。
Aliceがアカウントを作成
Chaperoneはホストからのこのエラーメッセージをサインアッププロセスを開始することで処理します。最初にAliceにサインアップダイアログを表示します。彼女はメールアドレスを入力し、強力なパスワードを作成し、フォームを送信します。
Chaperoneが彼女の認証情報を受信すると、それを誰にも送信し…ません。ライドシェアのUIもそれらにアクセスはできません。同一オリジンポリシーがそれをまたも阻止します。HoloルータとAliceが選んだホストもこの情報にはアクセスできません。(私たちがChaperoneをサーバ上でホストしている理由その2)。もし私たちが真実を言っているかどうか気になるのであれば、ソースを見てブラウザの開発ツールを起動して、Chaperoneがどんなものを送っているかを見ることができます)。
代わりに、ChaperoneがすることはAliceの資格情報を「種(シード)」として使って公開/秘密鍵ペアを作成することです。これにより、彼女のキーペアは一意であり、彼女だけが知っている情報からどのブラウザでも再構築できることが保証されます。シードはブラウザのlocalStorageに保存され、タブやページのリロードでアリスのキーペアを再生成できるようになります。そして、それはChaperoneによってのみ取得することができます。(同一オリジンポリシーによって)
さて、いよいよアリスが自分のホストに割り当てられる時が来ました。Chaperoneはアリスの鍵ペアの公開鍵をリゾルバサービスに渡し、新しいランダムな「ソースチェーンホスト」のセットを選択するように依頼します。(注: Holoベータ版では、ホストの信頼性を99.999%に高めるために5つのホストでAliceのソースチェーンを複製します)匿名インスタンスへの接続は閉じられ、新しいホストへの接続が開かれます。
利用可能なエージェント(ユーザー)用ホストが無い
この時点でChaperoneはエージェントのソースチェーン用のホストが無い状況に対応しなければならないかもしれません。これは「利用可能なホストがない」ケースと似ていますが、この場合は利用可能なホストがどれもソースチェーンホストとしての資格がないことを意味します。一旦ホストが選択されると、「ホストに接続できない」ケースに再び遭遇するかもしれません。
インスタンスが作成される
Chaperoneは新しいホストにAliceのアカウントを作成するように要求します。これは、アプリのバックエンドDNAのそれぞれの新しいインスタンスを作成し、それらを起動させ、彼女のソースチェーンを作成し、必要な初期化関数を実行することを含みます。
ホストがインスタンスを作成できない
ホストがAliceのために新しいDNAインスタンスを作成できなかった場合、(例えば、ホストのホロポートが忙しすぎたり、ストレージが不足していたり、DNAをホストしていない場合など)、または初期化関数がエラーを返した場合、Chaperoneにその旨を伝えます。Chaperoneは匿名モードに戻り、UIにエラーを返す前に役立つダイアログでエラーを処理する機会があります。(注意: この動作は変更される可能性があります。最初にChaperoneに他のソースチェーンホストを試させるかもしれません)
リゾルバでのホストの割り当てに失敗
Aliceの割り当てられたホストが彼女のためのインスタンスの作成に成功すると、彼女のChaperoneはリゾルバーサービスにこれを彼女の公式ホストとして登録するように依頼します。これにより、リゾルバは彼女が次にサインインしたときに同じホストを割り当てることができるようになります。しかし、この作業に何か問題があった場合、Chaperoneはエラーメッセージを表示します。これは非常に可能性が低く、バグのためかAliceが何か悪いことをしようとしている場合にしか起こりません。
アリスは別のコンピュータでログイン
次に、Aliceは彼女の携帯電話で同アプリを使用しようとします。もう一度、彼女が車を予約しようとすると、Chaperoneのiframeは画面全体を埋めるように展開します。この時、彼女はサインインフォームを選択し、資格情報を入力します。
ユーザーが存在しない
Aliceがユーザ名やパスワードを間違えて入力すると、Chaperoneは彼女がサインアップしたときに作成したものとは全く異なる鍵ペアを作成する。Chaperoneが割り当てられたホストのリゾルバサービスに問い合わせると、彼女の公開鍵を見たことがないと応答します。ChaperoneのUIはこの失敗モードを処理するために、彼女に再試行するかサインアップするかを尋ねます。
エージェント不明、検証失敗
これはもう二つの「絶対に起こってはならない」ケースです。
最初のケースでは、ホストはAliceのChaperoneに実際には彼女のインスタンスをホストしていないことを伝えます。二つ目のケースでは、ホストはAliceのインスタンスをホストしていることを認識していますが、彼女が自分のアカウントの鍵を持っているという彼女の署名された証明を認識していません。
Chaperoneはこれらのケースを一般的な「不具合が発生しました」というメッセージを表示することで処理するでしょう。
アリスはようやくサインインしてhAppを使用可能
Aliceは、任意のサインアップやサインインのナビゲートに成功すると、ついに自分のホストに接続して、DNAのバックエンドの関数を呼び出しています。開発者が適切に実装していれば、彼女のChaperoneは多くのエラーを見ることはないはずです。しかし、もちろん例外もあります。
hAppエラー
この種のエラーの最も可能性の高い原因はバリデーションの失敗でしょう。フロントエンドの開発者は、バックエンドのDNAにデータを送る前に事前に検証を行うことでこれらの問題を防ぐことが推奨されています。エラーの場合は、ChaperoneはこれらのエラーメッセージをUIに渡します。
もう一つのエラーは、2つの関数呼び出しが同時に実行されていて、両方がAliceのソースチェーンに書き込もうとした場合に発生する可能性があります。最初に書き込みを行った方はソースチェーンにロックがかかり、2番目の方は書き込みが拒否されます。これはUIが優雅に処理すべきことです。
最後に、DNAバックエンドにバグがある可能性もあります。その場合は、ChaperoneのUIがどのように処理すればいいのかわからなくなってしまいます。この場合は再度、開発会社に連絡する必要があるでしょう。
ホストとの接続を失う
Aliceは地下鉄に乗っていて、トンネルを通っている間に彼女は駅から彼女の家までの乗車予約をしようとしている間に接続を失います。Chaperoneは接続を再確立しようとし、最終的にはエラーを誘発します。
サービスロガーエラー、コンダクターエラー、ワームホールエラー
これら3つの失敗例は、ホスト上で何かが深刻な問題を起こしていることを示しています。Chaperoneがこれらを受信した場合は、「不具合が発生しました」メッセージを表示する前に、その問題自体を解決しようとしなければなりません。
障害モードが多い!
はい、そうです。UIとそれを提供するサーバー、Chaperoneとそれを提供するサーバー、Holoホストリゾルバサービス、Holoルーターゲートウェイ、ホストであるホロポート、それらが実行しているHolochainソフトウェア、そしてもちろんユーザーのためにホストしているDNAバックエンドなど、多くのコンポーネントがあります。これに加えて、アリスのブラウザ、彼女のコンピュータとOS、彼女のISPとルータメーカー、ホストのISP、そしてその間にあるすべてのネットワーク配管があります。私たちのコンポーネントを防御的にプログラミングすることで、開発者があらゆる種類の障害を優雅に処理できるツールを提供し、ユーザーに素晴らしい体験を提供できるようにすることを計画しています。
Juntoの進捗状況とHolochain開発者エコシステムへの貢献
今週は、Juntoの創設者であるエリック・ヤン氏とのエコシステムセッションの動画を公開しました。Holochain上での構築にコミットした最初のプロジェクトの一つであるJuntoは、ユーザーの尊厳を尊重し、オンライン世界との健全な関係を促進することを目的としたソーシャルメディアアプリです。現在、iTunes App StoreとAndroid Playストアで招待者のみが利用できるようになっていますが、現在のアルファ版で、招待者からの好意的なフィードバックを受けています。
エリック氏は、自分のチームがホロチェーンに惹かれたのは、ブロックチェーンよりもはるかにスケーラブルでエネルギー効率の高い可能性を秘めていたからだけではないと共有しました。彼はまた、私たちのチームのビジョンと哲学が彼らのビジョンとよく一致しているように見えたとも述べています。
“私たちがHolochainを選んだのにはいくつかの理由があります。何よりもまず第一に、彼らのプロジェクトのビジョンが私たちと非常に親和性があると感じたからです。Holochainは、人々がコントロールできる分散型ウェブの夢を実現してくれるので、私たちにとっても重要な存在です。人々が自分のデータの所有権を維持し、その主権を維持できるようにすることは、非常に強力なことです。”
– Junto共同創業者エリック・ヤン氏、2019年1月のインタビューにて
Eric氏はまた、Holochain上での開発の進捗状況や計画の詳細についても語ってくれました。現在、インフラはすべて中央集権化されていますが、彼らはいくつかの方法でHolochainの移行にハイブリッドなアプローチを開拓しています。
- 彼らはバックエンドAPIをGraphQLを使ったグラフデータベースとして設計しているので、Holochainに移植することができます。これは、HolochainのDHTが基本的にグラフデータベースであり、hAppsのための新しい開発ツールや文献の多くがGraphQLに焦点を当てているからです。
- 彼らは先に中央集権(集中)型を構築し、後にHolochainを構築するので、既存のコードベースを移行する最初のプロジェクトの一つになるでしょう。
- 彼らはHolochainのバックエンドをコンポーネントごとに開発しており、集中型と分散型の世界の架け橋となるアプリを実証する予定です。
- 彼らは、ユーザーが好みに応じて選択できるように、分散型(Holochain)、集中型(中央集権型クラウド)、中間型(Holoでホスト)のバックエンドオプションを持つことを計画しています。
Ericの言葉で彼らの計画を垣間見ることができます。
今のところ、私たちのアルファ版は、Rustを使って構築した集中型API上で動作しています。これはオープンソースのグラフデータベースで、準備ができたらHolochain上で完全に分散されるためのブリッジとして機能します。私たちは同時に、DM(ディレクトメッセージ)を始めとするHolochainのコンポーネントを構築しています。私たちは現在、Holochainのコンダクターを人々のモバイルデバイス上で動作させ、モバイルアプリ(Flutterで書かれた)にパッケージ化して、技術的なセットアップなしでこの技術を利用できるようにしようとしています。時間の経過とともに、Juntoのすべての機能をHolochain上に構築し、ユーザーが同じUI内でシームレスにインフラを切り替えられるように、集中型と分散型の両方の環境を用意していく予定です。
最後に注意すべき重要なことは、Holochain DNAの社会的文脈(表現、ソーシャルグラフ、社会的文脈など)での共有形質を定義していることです。ここでのアイデアは、holochainの開発者なら誰でも使える統一された標準を作ることで、アプリやユーザーインターフェースがより相互運用性の高いものになるようにすることです。
これに関する初期のブレインストーミングの一部をここに公開しました: https://github.com/juntofoundation/Holochain-Trait-Definitions
モバイルアプリもオープンソースです: https://github.com/juntofoundation/junto-mobile
Holochainのエコシステムへの貢献を計画しているとのことで、ワクワクしますね。Holochainはスマートフォンでも動作することを自慢してきましたが、アルファ版を完成させてベータ版に移行するために、これまではmacOSとLinuxにしか力を入れていませんでした。コミュニティの中に移植に協力してくれる味方がいるというのは心強いです。
また、相互運用可能なソーシャルグラフの実装のための標準を定義しようとしているのを見て嬉しく思います。もしこれがより広いコミュニティに採用されれば、ソーシャルメディアのhAppを実装したり、ソーシャルメディアに通信したいhAppのための共通言語を作ることになるでしょう。
開発状況
最新版
Holochain Coreリリース: 0.0.51-alpha1| 変更ログ
Holonixリリース:v0.0.81 | 変更ログ
Try-o-rama(エンドツーエンドテストツール)リリース:v0.3.4
hc-happ-scaffold: 0.1.0 (https://holochain.loveにて使用可能) | Project
Holoscapeリリース:v0.0.9-alpha (Holochain Core 0.0.47-alpha1を使用中)|ダウンロード
https://holochain.loveにて使用可能なバージョン
- Holonix: 0.0.81
- Holochain Core: 0.0.51-alpha1
- hc-happ-scaffold: 0.1.0