今までDiscordで会話したこと雑多まとめ

[suguru-toyohara]

Discord上のボイチャでお話ししたこと中心にまとめておきます。

[UtakataKyosui]

セキュリティどうしようかっていう
お話上がってます

何かご存知の方はこれの返信として下に繋げていってください

[haton14]

ログインやサインアップという文脈でしたらOIDCを使うとよいと思いますよ

• TwiiterならOIDCではないですがOAuth2.0
  • https://zenn.dev/kg0r0/articles/8b1cfe654a1cee
• Google, LINEなどならOIDC
  • https://developers.line.biz/ja/docs/line-login/integrate-line-login/

[UtakataKyosui]

ログインやサインアップに関しては「Clerk」というサービスもあります。
割と設定も簡単に出来た(少し触ったことがえる)ので、このようなプロジェクトで使えるかどうかやセキュリティ面については、ちょっと今日は調べきれないので、後日調べてみることにします
https://paiza.hatenablog.com/entry/2023/02/08/130000

[suguru-toyohara]

5chにセキュリティもクソもないのと同じで、
今目指してるプロダクト像には必要ないのかも？

セキュリティが必要な場面としては

• コンテンツ保護
• 入力コンテンツによってJavascriptが起動してしまうのを防ぐ(XSS)
• ユーザログイン（誰が発信しているか）

という3つの観点があります。

[Ryokugyoku]

基本公開するために情報収集するわけなので、ユーザログインを実装しない場合そこまでセキュリティを意識する必要はないかもしれません。
@suguru-toyohara さんが上げていただいている　XSSとSQLインジェクションくらいの対策で十分かもしれません。

[suguru-toyohara]

1/1 22時時点の情報です。間違ってたら訂正ください。

開発スタイル

• discussionベースで会話し、テーマごとにissuesを書いたりして、誰が何をしているのかを把握するスタイル
• discordボイチャで話をしたことは基本ここにまとめておきたい(あまりdiscordで会話するのも正直よくないが)

フロントエンド

• Next.jsで作成する。
  • バックエンドに負荷が集中する？とも思ったが、プロダクト作成を優先したい感じ。
  • スケールするプロダクトを作るという点では議論がある
• 一旦、別チームで画面を作ってもらう予定

バックエンド

• 一旦ECSで作成中。Dockerで起動するように主がやってる。
• 使える人が多いという意味でAWSを中心にインフラ・バックエンドを構成したい。
• Oracleとかそういうのは使わない予定。使用人口が多い技術を採択していきたい。
• 一旦ここまでがまとまっていることで、何も考えられていない。

セキュリティとスポンサー

• 自治体や国がスポンサーになってくれたら一番良いのにと思うが、セキュリティの面でちゃんとしないとOKはでなさそう。
• そうじゃなくてもLINEや企業がいいのかなと。

情報の真偽について

• 要件定義（第一フェーズ） #4 でも記入していたが、基地局ベースで現地情報かどうかを判別したいかも。

Nostrの分散型SNSは使わないの？

• これに関しては情報が分散してしまうという点がネック。どこにアクセスしていいかもわからないという点もあり、情報の真偽も不明。
• そこら辺をクリアできるなら、Nostrやmisskeyなどをベースにforkしても良い気はしている（これは私の意見）

[sokomin]

• スポンサーが付くことを考慮すると、様々な技術をつけるのは良いとして後で別インフラに移行できる状態にしたい。
• ホストがAWSだと東京-大阪で分散したとしても、AWS自体に障害がおこるとどうしようもない
  • Twitterなどの自社鯖を運用するとなると、スポンサーが必要そう
  • そうなると、スポンサーの意向で技術要件が変更される可能性があるので、Dockerのようなコンテナ構成があると良さそう

[sokomin]

多言語対応

• Twitterの「Google翻訳」ボタンを参考にツイート単位で訳す実行ができる形ならスケール可能そう
• google翻訳を各自使ってもらうのが良さそう
  • こちらはパイプだけ用意
  • GPT4を使うにしても、APIへの理解が必要

[UtakataKyosui]

提案

・同じ内容の再投稿をよく見かけるため、
木構造のように元の投稿を根にしてそこから生えた枝の投稿ですよ、みたいな表示のシステムとか作った方がよいのではないか

・Xで架空の市名で救援を求める投稿を見つけたため、そのような架空の市名が含まれている投稿は制限できるようにする機能があれば良いのではないだろうか

[sokomin]

位置情報（セキュリティというよりプライバシーの問題）

• 各々の意見
  • 位置情報ベースで情報共有する？
  • 災害時は全て公開してもらえたほうが良い（協力してくれる人を探す）
• 緊急通報ボタンはどう？
  • 複数人で投稿したらそれだけ困っている人がいる地域が可視化される
  • 村などの狭い地域にも対応する
• 性善説で作る方向でいきたい

[bytakumis]

位置情報を元にした情報提供は賛成です

災害時は匿名で表示、もしくは個々の情報は表示せずに分析データとして使用するのもありかもしれません

参考
Yahooの天気サービスでも似たものがありますが、位置情報をもとにして集計していますね
悪意あるユーザーが位置情報偽装する可能性もありますが。。。

[suguru-toyohara]

緊急通報システム

ワンボタンで助けを呼べるシステムを目指すと良いのかも。

少なくとも、

• 基地局情報
• GPS

の二つがちゃんと機能していれば、真偽不明ということはないはず。
これさえ実現できれば命を救えるプロダクトになりそうな予感する。

[acsses]

ここに入るのかわかりませんが・・・

例えば、電池残量に応じてポストに緊急性フラグを設定する、のはどうでしょう？

逃げ遅れた人の救助の際のトリアージ的判断の材料にもなりますし、逆に逃げ切れたけど電池がなくなった時の無事報告にも使えるかと思います。

[suguru-toyohara]

我々はAPIだけを提供すれば良いのでは？説

• APIを公開するだけで、Webフロントはみんなで作ってもらう形が良い気が
• 我々が関与すべきは、場の提供であってフロントの提供ではないかもしれない。
• 素早い展開ができる可能性

[UtakataKyosui]

・画像の遅延表示(一旦テキストだけ出す)
・画像の圧縮
・バックエンドの実装言語
・クラウドは何にするか(サーバインフラどうしよう)
・ネイティブアプリにするかPWAにするか
・災害時のオフラインモードをどうするか

[Shogo-Furuyama]

https://qiita.com/kei-dev/items/92d157a7f853de8758d0

• バックエンドとデータベース構築について
  • BaaSなどのフリーサービスを利用するのが手なのではないかと思います。
  • SupaBaseのフリープランが現状運用できそうなのでもし良ければURLの方からお願いします

[suguru-toyohara]

目指したいプロダクト像

• Twitterでの雑音・ノイズみたいなのが嫌で、埋もれちゃいそうな声とかを拾えるサービスを作りたい。
• 情報を提供したり得たりというので、災害に特化したものを作りたい。
• どっちかというと被災者向けのやつ

何かズレてたら教えてください 💦

[suguru-toyohara]

日本人の習性をハックする

• 「みんな逃げてますよ」mapを用いると、正常性バイアスに対抗できる可能性が高い。
• 今被災した人がどこに避難しているのか、gpsでマップにできると良いかも。
• ただし、赤信号みんなで渡れば怖くない理論でへんな誘導のされ方をするかもしれない点には注意した方が良いかもとは私は思った。
• (あと、避難所にいる人数によって、支援物資もどの程度必要なのかの提供もできると良いかもしれない。)

[suguru-toyohara]

2024/1/2 2:30現在のまとめ

ゴール設定

• ゴールとしては、
  • Geo + 固定情報発信で統計的に情報を得て何か発信するというシステム
• が良いかもしれない。
• 以下の点で良いのではないかと考えている。
  • シンプル
  • 騙しにくい（個では騙せるが、統計は騙せない）
  • 軽量
  • セキュア（ユーザが詳細な情報を提供しなくて良い）
  • 短時間でスケールしやすいアプリを作りやすい
  • 最終的にLINEなどのアプリと連携もしやすい（これは将来的なビジョン）
• 固定情報とは何か
  • 停電 (公式情報ではなく、現地情報で欲しい)
    • 全域で止めてるところもあれば、個々で繋がったりそうでないなどある。
    • また、5分先で電力が取れるとなれば電池切れの前に移動することもできる。
  • 断水 (停電と同様)
  • 浸水
  • 物資不足（医薬品なども含め）
  • 孤立
  • どこにどれだけ避難しているか
  • などの情報が最低限得られたら意味をなすはず。

懸念点

• 同時にセキュリティも強化しなければならない。
  • 将来的に災害インフラとしてのアプリになるなら、それ相応のものを作らねばならない。
  • アプリのせいで混乱を引き起こし、ない方が良かったと言われる世界線が存在することに注意。
• 情報が混乱をきたすこともあってはならない
  • ここに行けば電気がもらえたはずだったのに。みたいなことを言われると、アプリとしては立場がない。
  • 本当に統計情報だけを提供することが、いいことなのか、地獄の釜の蓋を開けることにならないか、注意する必要がある。
• もし本当にユーザの文字情報や画像情報が必要な場合はTwitterリンクを貼るが良いかも。→ただし、イーロンがそれを許すかは別

この話があがった本質的な話(3時追記)

• そもそもユーザはそんなリッチな情報源について、Twitter公式など、それ以上の情報は求めてない可能性が高い。
• 真偽不明情報が広がる可能性もあり、ここでは扱えない気がする。
  • もちろん、基地局+GPSで現地にないと得られない情報などに関して弾くことは可能
  • だとしてもそこまでやる必要があるか？という話がある
• そもそも帯域を圧迫してどうするという話がある。などなど...

その他上がった意見など。

• 5chとTwitterのいいとこどりみたいなことも考えた
  • 例えば、5chの板のような形で、Twitterがそれぞれで分割されているようなものだったり。
  • それでいて、情報の行き来ができるような仕組みを作るというパターンもあり。
• 最寄りの避難所どこ？みんなどこに避難している？というアプリでも良いかもと意見は出た。
• もし企業とコラボするには、それなりの実績が必要だよね。ということも意見として上がった。

[suguru-toyohara]

基地局調査は最終手段っぽいです。基本的には基地局のGIPは公開していないそうなので、
基本的にはgeo情報を信じるしかないという感じみたいです。

[suguru-toyohara]

大事なこと書き忘れてたのでここに。

コンセンサス

• 一旦ここまでで議論し切った感じがあり、これについて主が「思ってたんと違う」とならなければ、もう少し煮詰めてGOすれば良いかと。
• なので、ここまでで、違和感やこうしたいなどあればお願いします。

[suguru-toyohara]

ちょっとメモ

• そもそもWebサービスでできることってなんだろう。
• 出席してない人手あげて。というようなものだったりしないだろうか。
• 基地局が絶対安全、とはいかないだろう。
• とはいえ、できることはしたいよねと。

[suguru-toyohara]

https://twitter.com/Lily_to_Rose/status/1741812542547370037

[tecsoc]

統計情報を集める機能と、掲示板的機能で
思想や方向性が大きく違いそう、ということで別アプリ（リポジトリ）とすることにしました
https://github.com/tech-creative-club/disaster-platform

この辺のDiscordの投稿