ポイント機能

[jacopen]

どちらかというとオフライン向けだが、セッション参加のスタンプラリー機能が欲しい。

セッションに参加したらスタンプが貰えて、特定の条件を満たしていたら(○○セッション以上見るとか、特定のカテゴリのセッションをコンプするとか、色々)、賞品が貰えるor抽選権が貰える　みたいな。

しかしご時世的に物理スタンプはやりたくないので、これをスマホを活用して行えるようにしたい。

[jacopen]

全然関係ないけどスタンプラリーって英語なのか？と思って調べたらやっぱり和製英語らしい
https://eikaiwa.dmm.com/uknow/questions/64992/

[jacopen]

こんな感じの実装であれば、そんなに難しくはない・・・はず。

• チェックイン(スタンプラリー)向けのテーブルを作成
• Talkごとに定められた確認コード(確認コードはtalksテーブルにカラムを追加して設定) を含んだURLでQRコードを作成
• ユーザーがQRコードのURLにアクセスすると、ログインしているprofile_idとtalk_idがチェックインテーブルに記録される
  

そこから先、チェックインテーブルをどう使うかはコンテンツ側におまかせ。

[jacopen]

Dk本体に実装するなら瞬殺。

マイクロサービス的にやるんだったらもう一手間、二手間かかるかな。

[hrk091]

ポイント機能に関して、やるべきことを整理したいです。

思いつく範囲では、

• オフライン参加者向けに、上記のQRコード方式を実装する or 当日のオペレーションの混乱を避けるために別の方式を考える
• オンライン参加者向けに、一定時間視聴したらポイントを付与する実装を追加する
• early/late registration、当日のそれぞれでポイントを付与するバッチ処理を作って実行する
• 現在のポイントをdk-ui上で見えるようにする（ヘッダに足すとか）
• 各イベントがそれぞれ何ポイントか決める
• ポイントをランキング形式で出力できるようにする
• ランキング上位者に景品をお渡しするとして、どうやってその人達に伝えるかを考える。UIでの機能追加が必要なら実装する
• オンラインでポイント上位の人には何か特典ある？（特典が提供できないなら、オンライン参加者にはポイント付与やポイント表示しないほうが良さそう）

「当日のオペレーションの混乱を避けるために別の方式を考える」については、dkのオフライン用画面（chatだけが出るやつ）にcheck-inボタンみたいなのを追加して、各session枠でそれを押すことで参加したことにする、という案もできなくはないです。
ただ、それだと現地参加してなくても画面を出してクリックすればOKになってしまうので、現地にしつつセッションごとのQRコードを表示しないなら、jacopenさんが言っていたとおり同じQRコードを常に出しっぱなしにして、各セッション枠ごとに同じQRコードを何度も読んでもらう、という案になりそうです（ただ、これだとスタンプラリー感がなくなりますが。。。）

[hrk091]

pointEventIdの仕様について、以下でよいかコメントお願いします。

• 基底となるeventIdは、6桁の数字とする
  • セッション視聴の場合は、10(セッション視聴を示す固有ID) + day_id + [0-5] -> 101801, 101802, ... のような形とする
  • 他のeventの場合は、上2桁だけしっかり用途を決めて、下4桁はよしなに決めて良い
• dynamoのprimary keyとして、solt + 上記eventId をsha1にしたものを使う
  • なので、lambdaで受け付けるのはsha1の方で、受け取ったsha1でdynamoをqueryする
  • saltは、わかりやすさ重視で ${conference}/ を想定。なので、 11/21の午前セッションだと cndt2022/101800 をsha1にしたものを使う、という感じ
• URLのpath/query/bodyなど、外部に対してさらされる箇所についてはsha1を使う。QRコードに付与するのもsha1の方

pointEventTableの管理方法について

• pointEventTableの中身は、CDKで宣言的に管理する
  • 各環境へのdeployがやりやすい。別途自分でprovisioner相当を書くよりもこっちのほうが楽、あたりが理由
  • 環境間でeventIdが異なるケースがあるなら、対応が必要

[hrk091]

上記が可であれば、現地で読み込むQRコードも同じ方式で行こうと思います。
こちらはtrackIdを指定することになるので、 cndt2022/${trackId} を基底にする予定です。

[ystkfujii]

@hrk091

実装時の想定は下記の想定でした。

pointEventIdはユーザの想像のつかないユニークな値

#1625 (comment)

SHA1の場合、頑張ればだれでもポイントを登録できてしまう気がするのですが、別途ガードを入れる想定でしょうか？
（SHA1やめて乱数にしても総当たりされたら。。。ですが。。。）

[hrk091]

完璧な乱数にしてもよいのですが、環境間で可搬性をもたせたり、値を検証しやすくする観点で、saltを足してhashを算出する方法の方が建設的だなと思ってこっちにしてみました。

頑張ればだれでも

「どれくらい頑張る必要があるか」が重要なポイントだと思っていて、現時点で

• pointEventIdを知らなければならない
• （推測しやすい値だが）saltをしらなければならない
• その上でSHA1の実行が必要
  ので、2日間の会期中にここまでたどり着いたなら、もはやノベルティをあげてよいのでは、という気が個人的にはしています。

どちらかというと、このdiscussionとPRコメントに実行結果を貼ってるので、そっちの方がたどりつきやすそうですね（実行結果は消す予定です）
より堅牢にしたいなら、saltをrandomにしつつ、ストレッチングするとかですが、ストレッチングまではしなくてもという気がします。
githubに永続化されないrandom saltでhash生成するぐらいはやっとこうかな

[ystkfujii]

もはやノベルティをあげてよいのでは、という気が個人的にはしています。

LGTMですw

[hrk091]

藤井さんからの指摘と、この場所がオープンな場であることを加味して、saltはrandom secretを使うようにします。
個人的にはこれで十分かなと思っています