ChatGPTと話しながらスマホ対応p2p型掲示板を作るスレ

1 ：ぷにぷに名無しさん：2023/09/11(月) 19:20:37.40 ID:Ixsm/BSI0(スレ主)

Q. スマートフォンでも使用可能なp2p接続によるサーバーレス掲示板を作ることは可能ですか？

2 ：ぷにぷに名無しさん：2023/09/11(月) 19:21:25.30 ID:Ixsm/BSI0(スレ主)

A. はい、スマートフォンでも使用可能なP2P接続によるサーバーレス掲示板を作ることは技術的には可能です。P2P (Peer-to-Peer) 接続は、参加者同士が直接通信を行う技術で、中央のサーバーを必要としないため「サーバーレス」とも呼ばれます。P2P技術を利用した掲示板の実装には以下のようなステップが考えられます：

1. **P2Pプロトコルの選定**：BitTorrentやIPFS (InterPlanetary File System) などの既存のP2Pプロトコルを基にするか、独自のプロトコルを開発するかを決める必要があります。

2. **P2Pライブラリの利用**：多くのP2Pプロトコルには、開発を容易にするためのライブラリやフレームワークが存在します。これを使用してアプリケーションを開発します。

3. **モバイル対応**：スマートフォンでの使用を前提とする場合、モバイルプラットフォーム（iOSやAndroidなど）に対応したアプリケーションの開発が必要です。P2P技術の性質上、バックグラウンドでの動作やバッテリー消費に注意を払う必要があります。

4. **データ同期と一貫性**：P2Pネットワーク内でのデータの同期や一貫性を保つためのアルゴリズムや戦略を選定・実装します。例えば、CRDTs (Conflict-free Replicated Data Types) などの技術がこの目的で使われることがあります。

5. **セキュリティとプライバシー**：P2Pネットワークでは、全てのピアがデータの一部を持つ可能性があります。そのため、データの暗号化やアクセス制御など、セキュリティとプライバシーに関する対策も重要です。

6. **ディスカバリと接続**：新しいピアがネットワークに参加する際や、既存のピアとの接続を確立する際の方法を決定する必要があります。

P2P技術を使ったサーバーレス掲示板は、中央集権的なサーバーの制御や監視を避けることができる反面、技術的な複雑さやスケーラビリティ、セキュリティに関する課題が伴います。従って、開発にあたっては十分な調査や検討が必要です。

3 ：ぷにぷに名無しさん：2023/09/11(月) 19:24:04.56 ID:HYdHOcfI0

通信料的にヤバそう

4 ：ぷにぷに名無しさん：2023/09/11(月) 19:24:48.78 ID:Ixsm/BSI0(スレ主)

Q. 何から手をつけるべきですか？

5 ：ぷにぷに名無しさん：2023/09/11(月) 19:26:06.00 ID:Ixsm/BSI0(スレ主)

A. P2P接続によるサーバーレス掲示板の開発を始める際のステップについて、以下のように推奨されるアクションをまとめます：

1. **要件定義と調査**：
- まず、掲示板の具体的な機能や要件を明確にします。どのようなデータ構造やインターフェースを持つのか、どれくらいのユーザーをサポートするのかなど。
- 既存のP2P技術やライブラリを調査し、それらが要件を満たすか確認します。

2. **技術選定**：
- 最も適したP2Pプロトコルやライブラリを選定します。例: IPFS, WebRTC, BitTorrentなど。
- モバイルプラットフォームの選定。iOS, Android, React Native, Flutterなど。

3. **プロトタイプ開発**：
- まずは基本的な機能のみを持つシンプルなプロトタイプを開発します。これにより、選定した技術やアプローチの妥当性を早期に確認することができます。

4. **データ同期と一貫性の確保**：
- P2Pネットワークにおけるデータの同期や一貫性の問題を解決する方法を実装します。

5. **セキュリティ対策**：
- データの暗号化、アクセス制御、アンチスパムメカニズムなど、必要なセキュリティ対策を実装します。

6. **UI/UXの最適化**：
- スマートフォンの画面サイズや操作性を考慮して、ユーザーにとって使いやすいインターフェースをデザイン・実装します。

7. **テストとフィードバックの収集**：
- ユーザーグループやベータテスターを対象にテストを実施し、フィードバックを収集します。

8. **リリースと継続的なアップデート**：
- 公開した後も、ユーザーからのフィードバックを基に機能の追加やバグの修正を行います。

開始する際の一つの提案として、既存のP2P技術を活用することで、車輪の再発明を避け、開発の効率を向上させることができます。特に、IPFSやWebRTCなどの成熟した技術は、多くの資料やコミュニティが存在するため、情報収集やサポートが得られやすいです。

6 ：ぷにぷに名無しさん：2023/09/11(月) 19:27:48.01 ID:Ixsm/BSI0(スレ主)

Q.　テキストのみの掲示板とする場合、どのくらいの通信量が要求されますか？

7 ：ぷにぷに名無しさん：2023/09/11(月) 19:28:23.81 ID:Ixsm/BSI0(スレ主)

テキストのみの掲示板における通信量を評価する際、いくつかの要因を考慮する必要があります。

1. **投稿の平均サイズ**: たとえば、平均的なテキストの投稿が1KB（キロバイト）だとすると、1万件の投稿では約10MB（メガバイト）のデータが生成されます。

2. **アクセス頻度**: ユーザーがどれだけ頻繁に新しい投稿を読み込むか、または投稿をするかによって、通信量も変わってきます。

3. **P2Pのオーバーヘッド**: P2Pプロトコルは、データの交換だけでなく、ピアの発見やハンドシェイク、メタデータの交換など、追加の通信が伴うことが多いです。これにより、実際のテキストデータよりも多くの通信量が発生する場合があります。

4. **データの冗長性**: P2Pネットワークの性質上、同じデータが複数のピアによって保存・転送されることがあります。これにより、通信量が増加する可能性があります。

5. **更新と同期**: 新しい投稿があるたびに、それをすぐに全てのピアに同期するか、要求があったときだけ同期するか、または一定の間隔で同期するかによって、通信量も変わってきます。

具体的な数値を示すのは難しいですが、以上の要因を考慮してシミュレーションや実験を行うことで、実際の通信量を推定することができます。また、実際にプロトタイプを開発して実測することで、最も正確な通信量を知ることができるでしょう。

8 ：ぷにぷに名無しさん：2023/09/11(月) 19:30:53.79 ID:Ixsm/BSI0(スレ主)

Q. 要件定義をはじめたいです。どうすればいいですか？

9 ：ぷにぷに名無しさん：2023/09/11(月) 19:31:32.61 ID:Ixsm/BSI0(スレ主)

要件定義は、プロジェクトの成功のための基盤となるフェーズです。明確かつ詳細な要件を設定することで、後の設計や開発がスムーズに進行します。以下は要件定義を開始するためのステップです：

1. **プロジェクトの目的の明確化**：
- この掲示板を作成する主な目的や目標を明確にします。例: 「中央のサーバーを使わずに、ユーザーが直接情報を交換できる掲示板を作成する」。

2. **ステークホルダーの特定**：
- 誰がこの掲示板のユーザーになるのか、また、その他の関連する人々や団体（例: 管理者、開発者など）を特定します。

3. **ユーザーストーリーの作成**：
- ステークホルダーのニーズや望む機能を「ユーザーストーリー」として文書化します。例: 「ユーザーとして、新しいトピックを作成したい」というような形で。

4. **機能要件のリストアップ**：
- 必要な具体的な機能や機能の詳細をリスト化します。例: トピックの作成、コメントの投稿、スレッドの閲覧など。

5. **非機能要件の明確化**：
- 性能、セキュリティ、利用可能性、スケーラビリティなど、機能以外の要件を明確にします。

6. **制約条件の特定**：
- 技術的、運用上、または予算的な制約など、考慮すべき制約をリストアップします。

7. **優先順位の設定**：
- 全ての要件や機能に対して、優先度をつけます。これにより、後のフェーズでの作業の順番や、リリースを段階的に行う場合の計画が立てやすくなります。

8. **フィードバックの収集**：
- ステークホルダーや将来的なユーザーからフィードバックを収集し、要件に反映させます。

9. **ドキュメント化**：
- 上記の情報をすべて文書化し、要件定義書や仕様書としてまとめます。

10. **レビューと承認**：
- ステークホルダーや関連するメンバーと共にドキュメントをレビューし、必要に応じて修正を加えた後、承認を得ます。

要件定義は、プロジェクトの進行に伴って変更や追加が必要になる場合があります。そのため、柔軟に変更を受け入れることができるプロセスを確立することも重要です。

10 ：ぷにぷに名無しさん：2023/09/11(月) 19:33:25.03 ID:WnItw7KQ0

バッテリーと通信量とスペックがネックになりそうな気がする
技術的なこと分からんけど頑張って🥺

11 ：ぷにぷに名無しさん：2023/09/11(月) 19:33:28.88 ID:Rl5o8hAI0

P2P掲示板って言えば新月？とかいうの昔あったな　
あとPDに掲示板機能みたいなのあった気はする

12 ：ぷにぷに名無しさん：2023/09/11(月) 19:44:53.71 ID:MrbqJrI+0

gpt4？

13 ：ぷにぷに名無しさん：2023/09/11(月) 19:45:34.12 ID:Ixsm/BSI0(スレ主)

Q. プロジェクトの目的：中央のサーバーをなくすことにより、悪意のある攻撃者によるDDoS攻撃を防ぎたい。また、管理の非中央集権化をすすめることにより、管理者が不在でもコミュニティが崩壊しないシステムを構築したい。

ステークホルダーの特定：ターゲット層は匿名掲示板を主に利用する人を考えている。開発はあなたと私でやりましょう。管理については、ユーザーによる投票に基づいたミシュ主義的な方法を取るつもりである。

ユーザーストーリーの作成：ステークホルダーのニーズは、悪意のある荒らしユーザーを排除した、自由で闊達な言論空間。

機能要件のリストアップ
　必要な具体的な機能：スレッドの作成・スレッドに対するレス・スレッドの閲覧・それぞれの行動のログの保存・投票に基づいた悪意のあるユーザーの隔離

非機能要件の明確化
　性能は、1000レスを保存できるスレッドを常時100個程度維持できること。利用可能性とセキュリティについては、もう少し具体的に教えてください。

14 ：ぷにぷに名無しさん：2023/09/11(月) 19:46:28.80 ID:Ixsm/BSII(スレ主)

スマホから

>>10
聞いてみる🥺
>>11
PC限定なのがね
>>12
そう

15 ：ぷにぷに名無しさん：2023/09/11(月) 19:47:12.92 ID:Ixsm/BSI0(スレ主)

非機能要件の中の利用可能性とセキュリティについて、具体的に解説します：

### 利用可能性 (Availability)

1. **オフラインアクセス**: P2Pの性質を活かして、ユーザーがオフライン時でも一部の情報にアクセスできるようにします。
2. **ロバスト性**: 一部のピアがネットワークから離脱しても、システム全体が機能し続けること。
3. **スケーラビリティ**: 新しいユーザーが増加しても、システムが安定して動作し続けること。

### セキュリティ (Security)

1. **暗号化**: ユーザー間のコミュニケーションや保存データは暗号化されること。
2. **認証**: ユーザーは自分のアイデンティティを証明できる仕組みが必要です。匿名掲示板であっても、偽のユーザーや悪意のあるユーザーからの攻撃を防ぐためです。
3. **データの完全性**: 送受信されるデータが改ざんされていないことを確認する手段が必要です。
4. **アクセス制御**: 投票に基づいて悪意のあるユーザーを隔離する機能や、特定のコンテンツへのアクセスを制限する機能が考慮されるべきです。
5. **防御機構**: Sybil攻撃やEclipse攻撃など、P2Pネットワーク固有の攻撃からネットワークを守る機構の実装。

この要件に基づき、システムの詳細な設計を進めることができます。非機能要件は、システムの「質」に関わる部分であるため、設計や実装の初期段階から十分に考慮することが重要です。

16 ：ぷにぷに名無しさん：2023/09/11(月) 19:52:44.80 ID:HFhHw7RM0

やるやん

17 ：ぷにぷに名無しさん：2023/09/11(月) 19:55:40.32 ID:Ixsm/BSI0(スレ主)

Q　非機能要件は以下のようにします。
オフラインアクセスについて基本的にオンラインでのみ動作するようにします。
ロバスト性とスケーラビリティはできる限りほしいです。

通信の暗号化については重視しません。基本的に世界全体に公開するものだからです。
認証機能は非常に重要です。万全な認証機能を導入したいです。
データの完全性も重要視します。改ざんができない仕組みを導入したいです。
アクセス制御について：投票の結果悪意のあるユーザーだと認識された場合は、より詳細なペナルティを与える投票に移行することを考えています。その結果として書き込み禁止や、閲覧禁止の他に悪意のあるユーザーの隔離ができるシステムを実装したいです。
防御機構：攻撃から守る手段を導入したいです。

18 ：ぷにぷに名無しさん：2023/09/11(月) 19:56:04.95 ID:Ixsm/BSI0(スレ主)

非機能要件に基づいて、システムの設計を考える際の考慮点と提案を以下にリストアップします。

1. **ロバスト性 & スケーラビリティ**:
- **DHT (分散ハッシュテーブル)**: P2Pネットワークの中でデータの配置と検索を効率的に行うための方法としてDHTを利用することを検討します。

2. **認証**:
- **公開鍵基盤**: ユーザーは公開鍵と秘密鍵のペアを生成します。公開鍵はそのユーザーのIDとして機能し、秘密鍵はそのユーザーの行動を認証するために使用されます。
- **プルーフ・オブ・ワーク (PoW)**: 新しいユーザーがネットワークに参加する際のスパム防止として、計算的な課題を解決することを要求することも考慮します。

3. **データの完全性**:
- **Merkle Tree**: データの完全性を確保するため、Merkle Treeの使用を検討します。これにより、データの一部が改ざんされた場合にそれを検出できます。

4. **アクセス制御 & ユーザー隔離**:
- **投票システム**: 投票結果に基づき、ペナルティをユーザーに適用する機能を実装します。ペナルティの程度は、軽微から厳重までの段階を持つと良いでしょう。
- **ユーザー隔離**: 悪意のあるユーザーの情報は、特定の「隔離ゾーン」に保存することを検討します。これにより、正常なユーザーからのアクセスを遮断することができます。

5. **防御機構**:
- **リレイノード**: ユーザー間の通信を中継するノードを導入し、直接の通信を避けることで一部の攻撃を防止します。
- **リピュテーションシステム**: ユーザーの過去の行動に基づくスコアを導入し、信頼性を評価することで、悪意のあるユーザーや攻撃者を早期に検出します。

これらの考慮点と提案を元に、システムの詳細設計を進めることができます。設計や実装の際は、各要素の技術的な詳細や具体的な手法についても調査・検討する必要があります。

19 ：ぷにぷに名無しさん：2023/09/11(月) 19:58:20.57 ID:Ixsm/BSI0(スレ主)

Q　ここまでの要件定義をまとめてください。

20 ：ぷにぷに名無しさん：2023/09/11(月) 19:58:46.96 ID:Ixsm/BSI0(スレ主)

了解しました。以下に、これまでの会話を元に要件定義をまとめます。

---

### プロジェクトの目的:
- DDoS攻撃などの悪意ある攻撃からの防護。
- 管理の非中央集権化を通じて、管理者不在でもコミュニティが持続するシステムの実現。

### ステークホルダー:
- ターゲット層: 匿名掲示板を利用するユーザー。
- 開発者: あなたと私。
- 管理策: ユーザーによる投票を基盤としたミシュ主義的なアプローチ。

### ユーザーストーリー:
- 悪意のあるユーザーを排除した、自由で広範な言論空間を提供。

### 機能要件:
1. スレッドの作成。
2. スレッドへのレスポンス。
3. スレッドの閲覧。
4. 各行動のログ保存。
5. 投票に基づく悪意のあるユーザーの隔離。

### 非機能要件:

1. **オフラインアクセス**: 主にオンライン動作を前提とする。
2. **ロバスト性 & スケーラビリティ**: システムは一部のピアが離脱しても機能し続ける。新規ユーザー増加にも耐える構造とする。
3. **セキュリティ**:
- 通信の暗号化: 不要。
- 認証: 強固な認証機能を持つ。
- データの完全性: データ改ざんを防止する仕組みを導入。
- アクセス制御: 投票に基づき、悪意のあるユーザーへのペナルティを決定。隔離機能も含む。
- 防御機構: P2Pネットワーク固有の攻撃から保護。

---

上記が要件定義のまとめです。この要件を基に、システムの詳細設計や実装を進めることができます。

21 ：ぷにぷに名無しさん：2023/09/11(月) 20:01:17.55 ID:Ixsm/BSI0(スレ主)

Q　もっと詳細に記載すべきところはありますか？

22 ：ぷにぷに名無しさん：2023/09/11(月) 20:02:39.13 ID:Ixsm/BSI0(スレ主)

要件定義をさらに詳細にする際、以下の点を考慮して詳細化することが有効です。

1. **インターフェースの設計**:
- GUIの草案やモックアップの作成。
- ユーザーがシステムとどのように対話するかの詳細なシナリオ。

2. **データ構造**:
- スレッドやレスのデータ形式やデータベースのスキーマ。
- ユーザー情報、ログ情報などのデータ構造の詳細。

3. **プロトコルや通信方法**:
- ピア間の通信プロトコルやフォーマットの詳細。
- ネットワークトポロジーやピアの発見方法などの詳細。

4. **認証の具体的な手法**:
- どのような公開鍵暗号やプルーフ・オブ・ワークを使用するかの詳細。

5. **データの完全性**:
- Merkle Treeや他の技術をどのように実装するかの詳細。

6. **投票システムの詳細**:
- 投票の流れ、投票の持続時間、多数決の基準など。

7. **エラー処理**:
- 通信障害やデータ破損などのエラーが発生した際のユーザーへのフィードバックやリトライ戦略。

8. **ロードマップやフェーズ**:
- システムの開発やデプロイをどのような段階で行うかの計画。

9. **セキュリティ**:
- システムに対する潜在的な脅威やリスクの評価。
- これに対する対策や予防策の詳細。

10. **テスト戦略**:
- システムのどの部分をどのようにテストするか。
- ユニットテスト、統合テスト、性能テストなどの計画。

これらの詳細化は、実際の開発や運用に向けての具体的なガイドラインや指針となります。また、これにより潜在的な問題や課題を早期に発見し、解決策を検討することが可能になります。

23 ：ぷにぷに名無しさん：2023/09/11(月) 20:03:23.85 ID:Ixsm/BSI0(スレ主)

Q. もう少し詳しく教えてください。

24 ：ぷにぷに名無しさん：2023/09/11(月) 20:03:57.38 ID:Ixsm/BSI0(スレ主)

了解しました。以下に、上記で挙げた点について、さらに詳細を深掘りします。

1. **インターフェースの設計**:
- GUIデザインツールやプロトタイピングツールを使用して、具体的な画面のレイアウトや操作フローを作成します。
- ボタンの配置、色彩、文字の大きさなどのユーザビリティを考慮したデザイン。

2. **データ構造**:
- JSON, XML などのフォーマットを用いて、データの詳細な構造を定義します。
- どのようなデータをどの程度の期間保存するのか、保存形式は何か（例: SQL, NoSQL）などの具体的な情報。

3. **プロトコルや通信方法**:
- 使用するトランスポート層のプロトコル（TCP, UDP等）。
- メッセージ交換の手順やフォーマット、エンコーディングの方法など。

4. **認証の具体的な手法**:
- 例えば、RSAやElliptic Curveを用いた公開鍵暗号方式の具体的な仕様。
- トークンベースの認証や多要素認証の導入。

5. **データの完全性**:
- ブロックチェーンのような仕組みを利用して、データの変更履歴を保持。
- ハッシュ関数の種類や計算方法。

6. **投票システムの詳細**:
- 投票を開始するトリガー、投票に必要な最小参加者数、投票結果の確定方法など。
- 投票の期限や、投票結果の反映方法。

7. **エラー処理**:
- システムが不具合を検知した際のアラートやエラーメッセージの内容。
- ユーザーが直面する潜在的な問題に対するトラブルシューティングの手引き。

8. **ロードマップやフェーズ**:
- MVP（最小限の機能を持つ製品）の内容とその後のフェーズで追加する機能のリスト。

9. **セキュリティ**:
- システム内でのデータの暗号化方法やキーの管理方法。
- P2Pネットワーク固有の脅威（例: Sybil攻撃, Eclipse攻撃）に対する対策。

10. **テスト戦略**:
- テストの種類（ユニットテスト、統合テスト、性能テスト、セキュリティテスト）ごとの具体的なテストケース。
- どのようなテストツールやフレームワークを使用するのか。

これらの詳細は、プロジェクトが進行するにつれてリファインされることが一般的です。始めの段階では完璧である必要はありませんが、方向性やビジョンを明確にするための基盤として非常に重要です。

25 ：ぷにぷに名無しさん：2023/09/11(月) 20:04:34.62 ID:2Q4d+0r60

固定回線民にアップダウンして貰う
モバイルはダウンのみに

26 ：ぷにぷに名無しさん：2023/09/11(月) 20:06:04.90 ID:77pIiS4cI

おもろいことやってるね
これからコードまで作ってもらうようにできるもんなんか？

27 ：ぷにぷに名無しさん：2023/09/11(月) 20:07:15.85 ID:Ixsm/BSII(スレ主)

>>25
ここはまだ全然想像ついてない
>>26
わかんないからできるとこまで行ってみる

28 ：ぷにぷに名無しさん：2023/09/11(月) 20:08:57.52 ID:Ixsm/BSI0(スレ主)

Q　あなたが認識できる形のGUIはありますか？

29 ：ぷにぷに名無しさん：2023/09/11(月) 20:09:06.00 ID:09IXwTEc0

ユーザでp2pするメリットない
強いて言えばOrbitDBでも使ってDBを分散させたらってくらい

30 ：ぷにぷに名無しさん：2023/09/11(月) 20:09:26.51 ID:Ixsm/BSI0(スレ主)

私は直接的にGUIを表示する能力は持っていませんが、GUIの設計や概念に関するアドバイスや説明は行うことができます。具体的なGUIのモックアップやプロトタイプを作成する場合、以下のような手法やツールを利用することが一般的です：

1. **紙とペン**: 初期のアイディアを素早くスケッチするのに適しています。
2. **ワイヤーフレーム**: シンプルな線画で、ページのレイアウトや要素の配置を示すツール。例: Balsamiq, Wireframe.cc など。
3. **プロトタイピングツール**: より詳細でインタラクティブなデザインを作成することができるツール。例: Figma, Adobe XD, Sketch など。
4. **UIキット**: 一般的なUI要素やコンポーネントを含むテンプレート。これを利用することで、デザインの一貫性を保ちながら迅速にモックアップを作成することができます。

私はこれらのツールや方法に基づく説明や指示を提供することができますが、実際の画面表示やインタラクティブなデモを生成する能力はありません。

31 ：ぷにぷに名無しさん：2023/09/11(月) 20:10:32.68 ID:Ixsm/BSII(スレ主)

>>29
非中央集権型にしたいんだけどp2p以外でできるのかな

32 ：ぷにぷに名無しさん：2023/09/11(月) 20:11:01.98 ID:ruBTQp2A0

アプリケーションタイプの掲示板じゃダメなんかね
それこそスマホゲーからゲーム削除してゲーム内チャットだけ取り出したような

33 ：ぷにぷに名無しさん：2023/09/11(月) 20:13:06.88 ID:09IXwTEc0

>>31
マジな話、したいじゃなくて、こういう風にすれば実装できるって考えないと意味ない
Decentralizedにする明確な目的は？

34 ：ぷにぷに名無しさん：2023/09/11(月) 20:13:14.18 ID:Ixsm/BSII(スレ主)

>>32
それでもいいんだけど
サーバー無くしたいんだよね

35 ：ぷにぷに名無しさん：2023/09/11(月) 20:14:20.93 ID:Ixsm/BSII(スレ主)

>>33
ユーザー自身が運営できるというところかな
CAP不在の時間みたいなのが存在しない

36 ：ぷにぷに名無しさん：2023/09/11(月) 20:15:57.17 ID:EP/0WR9A0

freenet的な?

37 ：ぷにぷに名無しさん：2023/09/11(月) 20:18:03.52 ID:09IXwTEc0

>>35
それはモデレーションの話でシステム構成の話じゃないような...

38 ：ぷにぷに名無しさん：2023/09/11(月) 20:18:38.90 ID:9f630Sx60

ユーザー全員が強めの権限持つってこと？
1人ガイジ紛れ込んだだけでめんどくさい事になりそう

39 ：ぷにぷに名無しさん：2023/09/11(月) 20:19:57.88 ID:Ixsm/BSII(スレ主)

>>37
なんていうのかな
今の状態って一個のサーバーを提供するボランティアに全員が乗っかってるじゃん
この分の負荷は本来ユーザー全員で負うべきじゃないのかと思うんだよね

40 ：ぷにぷに名無しさん：2023/09/11(月) 20:20:35.42 ID:EP/0WR9A0

少なくとも実況には向かなそう

41 ：ぷにぷに名無しさん：2023/09/11(月) 20:20:55.93 ID:Ixsm/BSII(スレ主)

>>36
それが近いのかなあ
>>38
投票式で追放できるタイプにしたい

42 ：ぷにぷに名無しさん：2023/09/11(月) 20:22:34.58 ID:9f630Sx60

>>41
ふたばみたいな感じか

43 ：ぷにぷに名無しさん：2023/09/11(月) 20:23:16.90 ID:Ixsm/BSII(スレ主)

>>42
そうそう
ただもう少しエコチェン化は抑え込む仕様を実装したい

44 ：ぷにぷに名無しさん：2023/09/11(月) 20:25:38.94 ID:09IXwTEc0

>>39
それはコストの話？人的リソースの話？
何れにせよお金で解決できるから置き換え可能だよね
言ってることが全員で金出して運用しようとかわらんと思うけど

45 ：ぷにぷに名無しさん：2023/09/11(月) 20:31:22.76 ID:77pIiS4cI

昔あったnych.infoみたいな感じやろ

46 ：ぷにぷに名無しさん：2023/09/11(月) 20:36:10.63 ID:Ixsm/BSII(スレ主)

>>44
でもここにせよ防弾にせよ管理人が消えたらなくなるじゃん？
自分の理解だとp2p型ならそういうことがあってもユーザーが一人でも生きてたら残るという認識なんだけど

47 ：ぷにぷに名無しさん：2023/09/11(月) 20:43:08.91 ID:RYnNstI+0

p2p型掲示板ってなるとリアルタイム性の確保とか考えることはいっぱいあるよな
どうやってネームドガイジをBANする仕組みを作るのかとか、複垢を少なくしつつ匿名化を担保するのかとか

48 ： MouseTrap🪤 e93de3ab：2023/09/11(月) 20:45:05.62 ID:gPc2X28A0

ガ〜イ

49 ：ぷにぷに名無しさん：2023/09/11(月) 20:55:38.69 ID:Ixsm/BSI0(スレ主)

Q　技術的にできるのかもう一度詳しく教えてほしい

50 ：ぷにぷに名無しさん：2023/09/11(月) 20:55:55.78 ID:Ixsm/BSI0(スレ主)

了解しました。それでは、先に挙げた要件に基づいて技術的な実現可能性を詳しく検討してみましょう。

### 1. P2P接続

P2P技術は、中央サーバーを持たずに端末間で直接通信する技術です。BitTorrentやIPFS (InterPlanetary File System) などの技術がP2Pネットワークの一例です。

**実現可能性**: P2P技術を使用してデータ共有は可能ですが、ユーザーが多くなると、ネットワークの維持やデータの一貫性の確保が課題となります。また、スマートフォンのバッテリーや通信量の消費が問題になる可能性もあります。

### 2. スレッドの作成・レス・閲覧

これらの基本的な掲示板の機能は、P2Pネットワーク上でのデータ共有の仕組みを使用して実装することができます。

**実現可能性**: P2Pネットワーク上でのテキストデータの共有や取得は技術的に可能です。

### 3. 行動のログの保存

P2Pネットワーク上でのログ保存は、データの一貫性や可用性が課題となる可能性があります。

**実現可能性**: IPFSのような分散ファイルシステムを使用すれば、ログデータの保存や取得は技術的に可能ですが、データの永続性や速度、バックアップの問題が発生する可能性があります。

### 4. 投票に基づいたユーザーの隔離

この機能の実現には、P2Pネットワーク上での合意形成の仕組みが必要となります。

**実現可能性**: 分散型合意アルゴリズムやブロックチェーン技術を用いることで、P2Pネットワーク上での合意形成は技術的に可能です。

### 5. 認証機能 & データの完全性

ブロックチェーン技術や公開鍵暗号を使用することで、データの完全性の確保やユーザー認証が可能です。

**実現可能性**: 技術的に実現可能ですが、完全な匿名性を保つこととのトレードオフが発生する可能性があります。

### 総評

全体として、要件に基づいてのシステムの構築は技術的に実現可能ですが、多くの課題やトレードオフが存在します。特にP2P技術をスマートフォンで使用する際の性能やバッテリーの問題、ネットワークの一貫性やデータの可用性の問題など、注意深く検討する必要があります。

51 ：ぷにぷに名無しさん：2023/09/11(月) 20:56:24.47 ID:Ixsm/BSI0(スレ主)

Q　特にリアルタイム性の観点から教えてください

52 ：ぷにぷに名無しさん：2023/09/11(月) 20:56:41.45 ID:Ixsm/BSI0(スレ主)

リアルタイム性を考慮すると、P2Pの掲示板の設計にはいくつかの特有の課題が存在します。

### 1. **データ伝播の遅延**:

P2Pネットワークでは、データはノード間で直接共有されるため、データがすべてのノードに伝播するまでに時間がかかることがあります。

- **影響**: ユーザーAがメッセージを投稿した場合、他のユーザーがそのメッセージを即座に見ることができない場合があります。
- **解決策**: キャッシュ戦略や優先順位付けにより、頻繁にアクセスされるデータや新しいデータを優先的に伝播させる方法が考えられます。

### 2. **ノードの可用性**:

ノード（ユーザーの端末）は常時オンラインではないため、特定のノードからデータを取得することができない場合があります。

- **影響**: あるユーザーが投稿したデータが、そのユーザーの端末がオフラインの場合に取得できない可能性があります。
- **解決策**: データの冗長性を持たせ、複数のノードに同じデータを保存することで、一部のノードがオフラインになってもデータの可用性を保つ方法が考えられます。

### 3. **リアルタイムの合意形成**:

投票のような機能をリアルタイムに実現するためには、ノード間での高速な合意形成が必要です。

- **影響**: ノード間での通信遅延やデータの伝播遅延が発生すると、リアルタイムの合意形成が難しくなる可能性があります。
- **解決策**: 効率的な合意アルゴリズムや、投票の期間を設定して合意を形成する時間を確保する方法が考えられます。

### 4. **リアルタイムの更新通知**:

新しいメッセージや更新があった場合、リアルタイムで他のユーザーに通知する機能が求められます。

- **影響**: P2Pネットワークでは、中央のサーバーが存在しないため、すべてのユーザーにリアルタイムで更新を通知することが難しい可能性があります。
- **解決策**: P2Pネットワーク内でのサブスクリプションベースの通知システムや、特定のノードをリレーとして活用する方法が考えられます。

総じて、P2Pの掲示板のリアルタイム性の確保は、伝統的な中央サーバーを使用する掲示板に比べて難易度が高いと言えます。ただし、適切な設計と技術の選択により、これらの課題をある程度緩和することは可能です。

53 ：ぷにぷに名無しさん：2023/09/11(月) 20:57:12.84 ID:Ixsm/BSII(スレ主)

行けそう感ある気がする
所詮chatgptの言うことだけど

54 ：ぷにぷに名無しさん：2023/09/11(月) 21:00:27.15 ID:HFhHw7RM0

素朴な質問やが専ブラは使えないんよな？
JaneSpyleの事で懲りとるからアプリは怖いな

55 ：ぷにぷに名無しさん：2023/09/11(月) 21:02:36.30 ID:Ixsm/BSI0(スレ主)

Q. 専用のアプリケーションではなく、webブラウザから参加可能な方式は実現可能でしょうか？

56 ：ぷにぷに名無しさん：2023/09/11(月) 21:02:53.87 ID:Ixsm/BSI0(スレ主)

Webブラウザを使用してP2P通信を行うことは可能です。具体的には、WebRTCという技術を利用することで、ブラウザ間のP2P通信を実現することができます。

### WebRTCとは：

- **Web Real-Time Communication**の略で、ブラウザ間でのリアルタイム通信を可能にするオープンソースのプロジェクトです。
- 主にビデオやオーディオの通話を目的としていますが、任意のデータのP2P送受信も可能です。
- 主要なブラウザ（Chrome, Firefox, Safari, Edgeなど）でサポートされています。

### WebRTCを使用したP2P掲示板の実現：

1. **ブラウザのP2P通信**: ユーザーが掲示板にメッセージを投稿すると、WebRTCを使用して他のブラウザに直接データを送信することができます。

2. **シグナリング**: P2P通信を開始する前に、通信の詳細やセッション情報を交換するためのシグナリングが必要です。シグナリングサーバーとして、一時的に中央のサーバーを使用することが一般的です。ただし、このサーバーはデータの中央集約やストレージを行わないため、掲示板の分散性や中央サーバーのない特性は維持されます。

3. **データの伝播**: 一つのブラウザから他のすべてのブラウザにデータを伝播させるための効率的なアルゴリズムやネットワークトポロジーの設計が必要です。

4. **ブラウザの制約**: ブラウザでのP2P通信には、NATトラバーサルの問題や同時接続数の制約など、いくつかの技術的な課題があります。これらの問題を解決するためのSTUN/TURNサーバーやリレーノードの導入を検討することが考えられます。

要するに、Webブラウザを使用してP2P掲示板を実現することは技術的に可能ですが、上記のような複数の課題や制約を考慮して設計・実装を行う必要があります。

57 ：ぷにぷに名無しさん：2023/09/11(月) 21:09:16.12 ID:t0QKzpsU0

ニワカやけど掲示板そのものは大丈夫でもP2PってIPもろバレやしガイジに個人攻撃されそうって怖さはある
そういうのって作り次第で防げるもんなんやろか

58 ：ぷにぷに名無しさん：2023/09/11(月) 21:12:56.21 ID:J14QHhE+0

スマホのストレージとネットワークだけで実現は難しくないか？
クラウドフレアのワーカーDBと組み合わせたらいけそう
エッジ＋P2Pやな

59 ：ぷにぷに名無しさん：2023/09/11(月) 21:14:57.46 ID:J14QHhE+0

ワーカーDBには、ハッシュテーブルとかスレのインデックスとか置けば一貫性と完全性が保たれ信頼性も上がる

60 ：ぷにぷに名無しさん：2023/09/11(月) 21:15:02.77 ID:Ixsm/BSI0(スレ主)

Q　
参加者のIPアドレスなどの情報を完全に匿名化することは可能なのでしょうか

61 ：ぷにぷに名無しさん：2023/09/11(月) 21:15:37.88 ID:Ixsm/BSI0(スレ主)

完全にIPアドレスや他の特定可能な情報を匿名化することは非常に難しいですが、実際のIPアドレスを隠蔽したり、参加者の特定を難しくする手段はいくつか存在します。以下にその方法を示します：

1. **Torネットワーク**: Torは、インターネット上での通信を匿名化するためのフリーソフトウェアです。Torを通じてトラフィックをルーティングすることで、実際のIPアドレスを隠蔽することができます。

2. **VPN**: Virtual Private Network (VPN) は、インターネットトラフィックを暗号化し、異なる場所のサーバーを経由してトラフィックをルーティングするサービスです。VPNを使用することで、実際のIPアドレスをVPNプロバイダーのもので隠すことができます。

3. **リレーまたはプロキシサーバー**: これらのサーバーを介してトラフィックを転送することで、実際のIPアドレスを隠蔽することができます。

4. **P2Pの匿名ネットワーク**: 一部のP2Pネットワークは、参加者のIPアドレスの匿名化を目的として設計されています。これらのネットワークを利用することで、IPアドレスを隠蔽することができる場合があります。

5. **I2P**: これは匿名化されたP2Pネットワークで、トラフィックが多数のリレーを経由してルーティングされることで、参加者のIPアドレスを隠蔽します。

それでも、これらの手段を用いても完全な匿名性を保証することは難しい点を理解することが重要です。例えば、TorやVPNの終点サーバーが監視されている場合、トラフィックの出所や目的地を特定することができる可能性があります。

また、完全な匿名性を追求する場合、ネットワークのパフォーマンスやレスポンスタイムに影響を及ぼす可能性があります。これは、トラフィックを複数のリレーまたはサーバーを経由してルーティングすることに起因しています。

最後に、匿名化の技術やサービスを利用する場合、それに関連する法律や規制に注意を払う必要があります。

62 ：ぷにぷに名無しさん：2023/09/11(月) 21:16:06.00 ID:Ixsm/BSI0(スレ主)

Q　スマートフォンのストレージとネットワークのみで実装可能でしょうか？

63 ：ぷにぷに名無しさん：2023/09/11(月) 21:16:24.56 ID:Ixsm/BSI0(スレ主)

スマートフォンのストレージとネットワークのみを利用して、P2Pベースの掲示板システムを実装することは、理論的には可能です。ただし、以下の点に注意が必要です：

1. **ストレージ容量**: スマートフォンのストレージ容量は限られています。P2Pシステムでは、各ノード（この場合、スマートフォン）がデータの一部または全部を持つことになる可能性があります。そのため、長期的な使用や大量のデータのやり取りが予想される場合、ストレージ容量の問題が生じる可能性があります。

2. **ネットワーク帯域**: P2Pベースのシステムでは、多くのネットワークアクティビティが発生します。これにより、データ通信のコストが増加することが考えられます。特に移動体通信ネットワークを使用している場合、データ通信料金が高額になるリスクがあります。

3. **バッテリー消費**: P2P通信は、スマートフォンのバッテリーを大幅に消費する可能性があります。特に、多くのピアとの接続や頻繁なデータのやり取りが行われる場合、バッテリーの持ちが大きく低下する可能性があります。

4. **接続性**: スマートフォンのネットワーク接続は不安定であることがあります。移動中や電波の弱い場所では、P2Pネットワークへの接続が途切れる可能性があります。

5. **セキュリティとプライバシー**: スマートフォンのストレージにデータを保持する場合、デバイスのセキュリティとデータのプライバシーを確保することが重要です。デバイスが紛失・盗難された場合や、悪意のあるソフトウェアに感染した場合、保存されているデータが危険にさらされる可能性があります。

6. **データの整合性**: スマートフォンがP2Pネットワークから離脱・再接続する際、データの整合性を保つことが課題となる場合があります。

7. **ブラウザの制限**: 一部のP2P技術やプロトコルは、ウェブブラウザでは完全にサポートされていないか、ブラウザのセキュリティポリシーによって制限されることがあります。

これらの点を考慮し、適切な設計と実装を行うことで、スマートフォンのストレージとネットワークのみを使用したP2P掲示板システムを実現することは可能です。ただし、実際の運用環境やユーザーのニーズ、デバイスのスペックや通信環境など、多くの要因を考慮する必要があります。

64 ：ぷにぷに名無しさん：2023/09/11(月) 21:19:11.54 ID:Ixsm/BSII(スレ主)

>>58
>>59
ChatGPTに聞いてみる

65 ：ぷにぷに名無しさん：2023/09/11(月) 21:19:39.17 ID:Ixsm/BSI0(スレ主)

Q　クラウドフレアのワーカーDBと組み合わせる方式はどうでしょうか

66 ：ぷにぷに名無しさん：2023/09/11(月) 21:19:52.72 ID:Ixsm/BSI0(スレ主)

クラウドフレアのワーカー（Cloudflare Workers）は、クラウドフレアのCDNエッジ上でJavaScriptを実行するための環境を提供します。ワーカーDB（Workers KV）は、このワーカーズ環境上で利用できるキー-バリューストアのデータベースサービスです。これを用いることで、データをエッジ近くで保存し、高速にアクセスすることができます。

以下は、クラウドフレアのワーカーDBと組み合わせる方式についての考察です：

1. **低レイテンシー**: エッジコンピューティングを活用することで、ユーザーは最も近いエッジサーバーにアクセスすることができ、低レイテンシーでの応答が期待できます。

2. **グローバルなスケーラビリティ**: クラウドフレアのネットワークは世界中に広がっており、ワーカーDBを使うことでグローバルな規模でのデータアクセスが高速化されます。

3. **セキュリティ**: クラウドフレアは、DDoS防御やウェブセキュリティの機能を提供しています。これを活用することで、サービス全体のセキュリティを向上させることが可能です。

4. **コスト**: ワーカーDBの使用量やワーカーの実行回数に応じて料金が発生します。大量のアクセスやデータ保存が発生する場合、コストが増加する可能性があります。

5. **データの永続性**: Workers KVは高速な読み取りを目的としているため、頻繁な書き込みや大量のデータ更新は推奨されていません。P2Pの掲示板システムのデータ更新頻度や規模に応じて、実装戦略を見直す必要があります。

6. **組み合わせの検討**: P2Pネットワークとエッジコンピューティングの組み合わせは非常に興味深いです。例えば、ワーカーDBを中心的なキャッシュや一時的なデータ保存場所として利用し、P2Pネットワークをデータのバックアップや冗長性の確保に利用するといった方法が考えられます。

結論として、クラウドフレアのワーカーDBと組み合わせることで、P2Pベースの掲示板システムをより効率的に、高速に、そして安全に運用することが期待できます。ただし、コストやデータの永続性、アクセス頻度などの点を十分に考慮する必要があります。

67 ：ぷにぷに名無しさん：2023/09/11(月) 21:20:22.07 ID:J14QHhE+0

>>64
クラウドフレアのワーカーでDBリースされたのコテ氏の5月やぞ
学習データになさそう

68 ：ぷにぷに名無しさん：2023/09/11(月) 21:21:43.88 ID:J14QHhE+0

KVやなくてsqlite2走るようになったんや

69 ：ぷにぷに名無しさん：2023/09/11(月) 21:21:58.87 ID:Ixsm/BSII(スレ主)

これであってるのかよくわからん🥺
ChatGPT はたまに嘘つくから…

70 ：ぷにぷに名無しさん：2023/09/11(月) 21:23:30.12 ID:zEi9PJoo0

IPFSみたいなの考えたほうがええんちゃうかなあ

71 ：ぷにぷに名無しさん：2023/09/11(月) 21:29:43.12 ID:J14QHhE+0

エッジ使うとなると、出自を隠すためにどうするか工夫が必要やな

72 ：ぷにぷに名無しさん：2023/09/11(月) 21:34:05.02 ID:zEi9PJoo0

たまにって言うけどなんか正解率ゴミになってるから頻繁に間違えるようになってたの今日触ってみて確認できたわ
ニュースになってたけど間違いやなかったんやなって

73 ：ぷにぷに名無しさん：2023/09/11(月) 21:34:40.64 ID:Ixsm/BSII(スレ主)

>>72
GPT4でも？🥺

74 ：ぷにぷに名無しさん：2023/09/11(月) 21:35:55.00 ID:zEi9PJoo0

>>73
Bingのほうしか触ってないからわからんがマシやけど微妙かなぁ

75 ：ぷにぷに名無しさん：2023/09/11(月) 21:51:39.85 ID:Ixsm/BSII(スレ主)

まあ何はともあれ要件定義というやつを完成させたら何とかなる気がしてる
ワイちゃん何を隠そうプログラミングなんて数値計算とVBAしかやったことないからChatGPT におんぶに抱っこでやってみようという感覚なんよ

76 ：ぷにぷに名無しさん：2023/09/11(月) 21:54:56.74 ID:EP/0WR9A0

言語は何で作んの?

77 ：【ぷにん法帖Lv.10 (LvUPまであと23時間0分)】：2023/09/11(月) 21:56:10.30 ID:LSoTDjjk0

酷い言葉浴びせたい気分になるスレ

78 ：ぷにぷに名無しさん：2023/09/11(月) 21:56:25.68 ID:zEi9PJoo0

なんとかなったらええのにな

79 ：ぷにぷに名無しさん：2023/09/11(月) 21:57:42.09 ID:zEi9PJoo0

>>77
AIがポンコツなのが悪い😡

80 ：ぷにぷに名無しさん：2023/09/11(月) 22:02:31.78 ID:Ixsm/BSII(スレ主)

>>77
いいぞ😡

81 ：ぷにぷに名無しさん：2023/09/11(月) 22:04:00.19 ID:Ixsm/BSII(スレ主)

>>76
ChatGPT に聞いてみるか

>>78
ダメそうなのね🥺

82 ：ぷにぷに名無しさん：2023/09/11(月) 22:06:06.10 ID:Ixsm/BSI0(スレ主)

Q　プログラミング言語は何が必要でしょうか？

83 ：ぷにぷに名無しさん：2023/09/11(月) 22:06:23.08 ID:Ixsm/BSI0(スレ主)

プロジェクトの要件を考慮すると、以下のようなプログラミング言語や技術が必要になります：

1. **フロントエンド (Webブラウザ上で動作する部分)**:
- **JavaScript**: クライアントサイドの動的処理を担当します。現代のWeb開発においては必須の言語です。
- **TypeScript**: JavaScriptのスーパーセットで、静的型チェックを提供します。大規模なプロジェクトやチーム開発に適しています。
- **フレームワーク**: React, Vue, Angularなどのフレームワークを利用すると、効率的にUIを構築することができます。

2. **バックエンド (P2Pネットワークなどのサーバーサイド処理)**:
- **Node.js**: JavaScriptのランタイムで、サーバーサイドでのJavaScriptの実行を可能にします。多くのP2PライブラリやツールがNode.js向けに提供されています。
- **Go (Golang)**: P2Pネットワークの実装やブロックチェーン技術に関して、Go言語は人気があります。高性能かつ並行処理に優れています。
- **Python**: サーバーサイドの開発にも広く使われていますが、P2Pの実装に関するライブラリやツールが限られている場合があります。

3. **データベース**:
- 既存のリレーショナルデータベースやNoSQLデータベースを利用する場合は、**SQL**やそのデータベース特有の言語やAPIに精通している必要があります。
- P2Pの場合、分散型のデータベースやブロックチェーン技術を使用することも考えられます。

4. **P2Pやブロックチェーン技術**:
- P2P通信のためのライブラリやフレームワークには特定の言語で書かれているものが多いので、その言語の習得が必要になります。
- 例えば、EthereumのSmart Contractを利用する場合は、**Solidity**という言語を学ぶ必要があります。

5. **セキュリティ**:
- 認証、暗号化、データの完全性確保などのためのライブラリやツールを使用する場合、その技術や言語の理解が必要になります。

開発を始める前に、どの技術や言語が適しているかを検討し、その言語や技術に関する学習を進めることがおすすめです。

84 ：ぷにぷに名無しさん：2023/09/11(月) 22:07:03.98 ID:Ixsm/BSII(スレ主)

ゼロスタートだと年単位でかかる気がしてきた

85 ：ぷにぷに名無しさん：2023/09/11(月) 22:08:30.89 ID:zEi9PJoo0

というかやなp2pにしたとしてクライアント要は専ブラどうすんのよ？問題が残ってるんやで
クライアントに通せるプロキシアプリも作らんとあかん

86 ：ぷにぷに名無しさん：2023/09/11(月) 22:13:20.96 ID:Ixsm/BSII(スレ主)

>>85
Webブラウザで行けるって聞いたの🥺
>>56

87 ：ぷにぷに名無しさん：2023/09/11(月) 22:14:53.22 ID:Q2+lgGsEI

p2p掲示板といえば新月やと思うけどあそこまだ住民いるんやろか

88 ：ぷにぷに名無しさん：2023/09/11(月) 22:28:22.53 ID:zEi9PJoo0

>>86
行けなくはないけどi2pとかtorでもわかるように裏でそれ用のソフト動いてるんやで

89 ：ぷにぷに名無しさん：2023/09/11(月) 22:37:25.39 ID:Ixsm/BSII(スレ主)

>>88
結局アプリ作らないとダメなのね🥺

90 ：ぷにぷに名無しさん：2023/09/11(月) 23:10:21.77 ID:KNh2z1lEI

autogpt使うと自動でプログラム書いて実行可能になるまでデバッグまでしてくれるらしい

91 ：ぷにぷに名無しさん：2023/09/12(火) 01:03:23.57 ID:RYzY7iV60

ワイもまさにイッチが思ってるようなP2P型掲示板に賛成や
共有NGみたいな感じで一定の閾値超えたら
シードデータからそのIDを削除するみたいなシステムにすればええと思う

ただし閾値の設定がユーザー数に比例して変わっていかないと
人が少ない時と多い時でNG基準が変わりそうやね

92 ：ぷにぷに名無しさん：2023/09/12(火) 08:17:10.09 ID:r9q4bBEoI(スレ主)

技術的な面は後から考えるとして機能だけ先に考えちゃうのがいいかな
作りたいと思うことが大事ってプログラミングスレでよく言われてるし🥺

93 ：ぷにぷに名無しさん：2023/09/12(火) 12:25:51.37 ID:j7zrQaKw0

盛大なものを作ろうとすると失敗するという昔から言われていること繰り返すのか
chatgptなんて嘘を平気で真実ですと胸はって言う虚言癖なんだから

94 ：ぷにぷに名無しさん：2023/09/12(火) 12:30:31.04 ID:vaPmlm9c0

7月にはiOSの専ブラを作る！と意気込んでた人が多発していたが
そのうちの何人が続けてるのだろうか

95 ：ぷにぷに名無しさん：2023/09/12(火) 13:44:34.98 ID:nQiLhaXk0

絶対にないと使えない部分だけを考えよう
NGの仕組みは今考えるには難しすぎる
改竄防止機能を搭載するとなると必然的にピア間の合意形成の仕組みが必要になる
そこを作ってからでないと決まらない部分もあるから色々と難しい
改竄防止機能を一旦作らないならチャットみたいなものになるが簡単に作れると思うんだけど

96 ：ぷにぷに名無しさん：2023/09/12(火) 13:52:05.41 ID:wmjQMhmoi

スレの保持と内容の担保をどうするかってのがおそらく肝やからな

97 ：ぷにぷに名無しさん：2023/09/12(火) 18:14:26.71 ID:EA6lyiso0

坑拘降ん甲域せも功康為医も実候荒ろわおめ荒わ考たな降郊