Kaki ()
ユーザのポイント数を複数のシステム間で共有できないかと考えておりますが、
Addressを共有する必要が出てくるかと思います。
ユーザーは複数のシステムで任意に登録できるようにしたいのですが、
その場合Addressはどのようにして同期すればいいでしょうか？
どれかのシステムが中央管理システムのようにユーザーIDとAddressをまとめて管理する必要が出てきますでしょうか？
まだMijinについてあまりよくわかっていないものでして、よろしければご教授いただければと思います。
よろしくお願いいたします。
Addressを共有する必要が出てくるかと思います。
ユーザーは複数のシステムで任意に登録できるようにしたいのですが、
その場合Addressはどのようにして同期すればいいでしょうか？
どれかのシステムが中央管理システムのようにユーザーIDとAddressをまとめて管理する必要が出てきますでしょうか？
まだMijinについてあまりよくわかっていないものでして、よろしければご教授いただければと思います。
よろしくお願いいたします。
LHJ ()
Kakiさん、おはようございます。
実に興味深い POST で感謝致します。
まず、以下のサイトが参考になるかもしれません。mijin 公式ブログです。
アカウント情報を格納するDBは別とするイメージでしょうか。これは既存システムとの連携や運用も考慮して おられるのではないかと「空想」しております。
http://mijin.io/ja/525.html
次に、ユーザーのポイントを mijin における mosaic と整理します。
例えば、Webショッピングでお買い物をしたとき、法定通貨（JPY）やクレジットカード（VISA/Master）で決済し、ポイントは mosaic で高速送金するという仕組みですね。キャンページ時は、複数の Address に1トランザクションで mosaic を高速送金することもできるでしょう。
こう考えると、本 POST で言う「どれからのシステム」は 1. が担うことになるのではないでしょうか？
そして、重要なノード（今回は Server ）になるので、マルチシグネチャ（複数署名）を行うことで、送金ミスやセキュリティリスクの低減が期待でき ます。既存システムが mijin の API を叩くことで実現できる「はず」なので、HW/SWの全面リプレースは不要でしょう。
以上について、LHJさんは mijin の中の人ではないので間違っていたら、管理者様や Takanobu さんがツッコミしてくれると考え、まずは POST してみました。
Let's think together !
実に興味深い POST で感謝致します。
まず、以下のサイトが参考になるかもしれません。mijin 公式ブログです。
アカウント情報を格納するDBは別とするイメージでしょうか。これは既存システムとの連携や運用も考慮して おられるのではないかと「空想」しております。
http://mijin.io/ja/525.html
次に、ユーザーのポイントを mijin における mosaic と整理します。
- mosaic は xem を所持している Address が、namespaces で mosaic 名を定義し、mosaic 量を好きなだけ発行します。ただし、発行手数料（ xem ）は発生します。
- これで、 mosaic をたんまり所持している Address が、本 POST で言うユーザー（複数の Address ）へ、1トランザクションで mosaic を高速送金することができます。
- 複数の Address は mosaic を取得することができました。
例えば、Webショッピングでお買い物をしたとき、法定通貨（JPY）やクレジットカード（VISA/Master）で決済し、ポイントは mosaic で高速送金するという仕組みですね。キャンページ時は、複数の Address に1トランザクションで mosaic を高速送金することもできるでしょう。
こう考えると、本 POST で言う「どれからのシステム」は 1. が担うことになるのではないでしょうか？
そして、重要なノード（今回は Server ）になるので、マルチシグネチャ（複数署名）を行うことで、送金ミスやセキュリティリスクの低減が期待でき ます。既存システムが mijin の API を叩くことで実現できる「はず」なので、HW/SWの全面リプレースは不要でしょう。
以上について、LHJさんは mijin の中の人ではないので間違っていたら、管理者様や Takanobu さんがツッコミしてくれると考え、まずは POST してみました。
Let's think together !
Takanobu ()
Kakiさん、はじめまして。
議論のネタ、ありがとうございますｗ
LHJさん、ご指名ありがとうございます。
ちょっと異なる視点から回答してみます。
質問の意図は、
ユーザが複数の異なるショップで別々のタイミングでポイント会員になったとした場合、
例えばショップAで会員になった場合にAddress-Aが割り当てられて、
次にショップBで会員になった場合に、どうやってAddress-Aを紐づければよいか？
ショップをまたがって管理する大規模システムは構築したくない。
という内容でしょうか？
基本的にはユーザ側にAddressを持ち歩いてもらい、
ショップBで会員になった場合にそのアドレスをショップBシステムに登録する。
という流れになるかと思います。
Addressを持ち歩かせる手段がない場合は、ご察しのとおり、
それぞれの店舗で新規に発行されるAddress を
メールアドレスなど個人を特定できるIDで名寄せするシステムが必要かと思います。
論点がずれておりましたら、ご指摘ください。
議論のネタ、ありがとうございますｗ
LHJさん、ご指名ありがとうございます。
ちょっと異なる視点から回答してみます。
質問の意図は、
ユーザが複数の異なるショップで別々のタイミングでポイント会員になったとした場合、
例えばショップAで会員になった場合にAddress-Aが割り当てられて、
次にショップBで会員になった場合に、どうやってAddress-Aを紐づければよいか？
ショップをまたがって管理する大規模システムは構築したくない。
という内容でしょうか？
基本的にはユーザ側にAddressを持ち歩いてもらい、
ショップBで会員になった場合にそのアドレスをショップBシステムに登録する。
という流れになるかと思います。
Addressを持ち歩かせる手段がない場合は、ご察しのとおり、
それぞれの店舗で新規に発行されるAddress を
メールアドレスなど個人を特定できるIDで名寄せするシステムが必要かと思います。
論点がずれておりましたら、ご指摘ください。
Kaki ()
LHJさん、Takanobuさん
ご回答ありがとうございます。
質問の意図としてはTakanobuさんの内容となります。
やはり、名寄せシステムが必要ですよね。。。
どう管理すればいいか考えてみます。
また、LHJさんのおっしゃる通りの仕組みも検討していますので、
こちらも実際にAPIを触りながら色々確認してみたいと思います。
他にも質問させていただくかもしれませんが、よろしくお願いします。
ご回答ありがとうございます。
質問の意図としてはTakanobuさんの内容となります。
やはり、名寄せシステムが必要ですよね。。。
どう管理すればいいか考えてみます。
また、LHJさんのおっしゃる通りの仕組みも検討していますので、
こちらも実際にAPIを触りながら色々確認してみたいと思います。
他にも質問させていただくかもしれませんが、よろしくお願いします。
Takanobu ()
管理の方法ですが、マルチシグを検討されてもよいかもしれませんね。
実際の財布(Alice) は最初に会員になったときに作っておいて、
ショップAで作成したアカウントから送金可能なようにしておきます(1 of n で構築)。
そのあと、その他の会員になったときには随時マルチシグアカウントを追加していくイメージです。
こうしておけば、それぞれの店舗で独自のトークンを使ってAlice のポイントを出し入れできます。
ただ、マルチシグを構成するときにAliceのトークン情報をどこからか引っ張ってこないとだめですが。
実際に動作確認していない部分もありますが、基本的には可能かと思います。
ご参考まで。
実際の財布(Alice) は最初に会員になったときに作っておいて、
ショップAで作成したアカウントから送金可能なようにしておきます(1 of n で構築)。
そのあと、その他の会員になったときには随時マルチシグアカウントを追加していくイメージです。
こうしておけば、それぞれの店舗で独自のトークンを使ってAlice のポイントを出し入れできます。
ただ、マルチシグを構成するときにAliceのトークン情報をどこからか引っ張ってこないとだめですが。
実際に動作確認していない部分もありますが、基本的には可能かと思います。
ご参考まで。
takao ()
皆さんの返答が素晴らしくて出る幕なし！