web3ログインとiframeで広がる新しい市場について考える
はじめに
- 紹介しているビジネスモデルについて法的に問題がないことを保証するものではありません。
- 参考までにですが、本記事の執筆現在このビジネスモデルを活用したアプリを開発中です。 法的な問題について方針レベルでは問題がないことを確認済みですが、さらなる精査にむけて仮リリース後、弁護士の方に触ってもらい確認してもらうというプロセスを踏む予定です。
- すこしお堅いことを書きましたが、この記事が新しい挑戦をする人たちの助けになればなによりです。
概要
趣味で作っているアプリの開発中にOSSを開発している方に機能の追加依頼したところ快く追加してもらえたということがあり、せっかくなら多くの人に知ってもらいたいと思ったことがこの記事を書こうと思ったきっかけです。 私個人のアイデアについても書いてますが、裏付けなどはないですのでそういう世界も面白いな程度の感覚で読んでもらえればと思います。
具体的に追加していただいた機能は、iframe内のページに対して仮想通貨walletが有効になる機能です。 その機能によって、
- 1: webページへマネタイズ済みの素材ページを組み込める
- 2: 組込まれた素材ページへのユーザ認証の手間の省略
備考: 素材ページはiframeの子側のwebページのこと
ができるようになりました。(検証済み)
これらが、webページを別のwebページの素材として販売するような市場の開拓につながっていくと考えています。
想定する技術スタック
- ブロックチェーン: symbol
- 仮想通貨wallet: SSS Extension <- 今回機能追加をしてもらったOSS
- ブラウザ: Chrome (chrome拡張が動くブラウザなら動くかも? 未確認)
前提とする課金モデルについて
今回想定するビジネスモデルは一般的なサブスクリプションに似ています。
これらは一定の金額を支払いサービスを使うという点で同じものとなります。
その一方で、仮想通貨walletを使わないといけなかったりそもそも仮想通貨を持っていないとサービスを使い始められなかったりブロックチェーンを活用したものは、ユーザにとってハードルになりそう
一般的なサブスクリプション
ブロックチェーンを活用
ポイントシステムのフロー(未検証 今後検証予定)
ユーザと運営のやりとりの1例
- ①: ユーザは、仮想通貨(xym)を支払う
- ②: アプリ運営は、支払われた仮想通貨(xym)に相当するpoint(token)をユーザのwalletへ送る
- ③: ユーザは、webページを訪れてサービスを利用する
- ④: アプリ運営は、ユーザ認証のログからユーザwalletから1pointを回収する※
- 備考1: tokenの発行時点で回収可能(revocable)の設定をしているものとする
- ⑤: ユーザは、pointがwalletにない場合にサービスを利用できない
- ⑥: アプリ運営は、pointを持っていないユーザにサービスを提供しない
このポイントシステムはブロックチェーンのsymbolのrevocableなtoken(mosaic)を使うことで、ユーザのポイント使用で発生する手間を省略。ユーザは最初にpointを払ったらそれ以降はpointの支払いなどの煩わしい手間を意識せずに利用できて便利。
他にも、ユーザがxymを所持していなかったとしてもpointさえ持っていれば利用し始められるため、仮想通貨を購入したことがない初期ユーザへのキャンペーンなどでうまく使える(かも)。
1: webページへマネタイズ済みの素材ページを組み込める
上の画像では、jupyter notebookというpythonの統合開発環境(webページ)からiframeでwebアプリにアクセスしています。(検証済み)
もしすでにwalletをinstallしているならこちらのページ(https://pycetra.github.io/iframe_web_parent/99_symbol.html) で動作確認ができます。
(画像から問題なくログインできていることがわかる)
また、jupyter notebookはJavaScriptを実行できるため、iframe間でpostMessageによって受け渡した変数をpythonへ渡すことができます。(参考link: https://mybinder.org/v2/gh/pycetra/home/HEAD?urlpath=tree/010_ipython_kernel_postmessage.ipynb ※)
つまりwebアプリ内で作った変数を別言語の変数へ移動することができるということ!
今後この仕組みを活用したwebアプリがたくさんでてきたら、pythonや他の言語でもリッチなGUIからconfigの作成やもしかしたらコードの作成もできるかもしれないですね。
この仕組みから、エンタープライズに組み込まれるOSSではなく、OSSに組み込まれるエンタープライズという立ち位置のアプリが生まれOSS開発者に好まれて使われると考えます。 ただし、GUIでしか使えないという性質からソースコードに組み込まれる(GitHubなどで管理される)とは考えにくく、プロジェクト終盤での利用頻度は減っていき最終的には削除されると思います。 これはデメリットに見えますが、逆にエンジニアからするとそのような使い方ができるということで好まれる性質です。
2: 組込まれた素材ページへのユーザ認証の手間の省略
こちらもjupyter上で2つのwebアプリに同時にアクセスしています。(検証済み)
読み込みの関係上なのか動作が不安定ですが、ユーザ認証の手間(ユーザ名,パスワードの入力)なく自動でログインできています。
これを活用すると、フロントエンドは複数のwebアプリを組み合わせて使うことが可能になります!
この仕組みから、複数回の画面遷移を必要とするつぎはぎだらけの操作感ではなく、連続的で全体感のあるSinglePageApplicationライクなユーザ体験がより一層磨かれると考えます。 ただし、素材ページ複数使うためページ全体の統一感などが崩れるリスクがあり、部分的な導入(プロトタイプ)にとどまるかもしれません。
まとめ
walletがiframeを読み込めることになったことで、
- 1: webページへマネタイズ済みの素材ページを組み込める
- -> OSSに組み込めるエンタープライズ製品というマーケットの可能性!
- 2: 組込まれた素材ページへのユーザ認証の手間の省略
- -> webアプリの素材ページとしてのマーケットの可能性!
Discussion