Merge branch 'main' into docs/Differences_in_handling_user-dependent_…

…and_non-user-dependent_data

.prh/suteravr-words.yaml

@@ -55,13 +55,22 @@ rules:
     pattern:
       - /(?<!`)(Object(-|\s)?Storage)(?!`)/gi
 
-  - expected: Socialコンポーネント
+  - expected: Relayコンポーネント
     pattern: 
-      - /(?<!`)(Social|SuteraVR)(コンポーネント|component|サーバー|server|ブルーム|bloom)(?!`)/gi
+      - /(?<!`)(Relay|Social|SuteraVR)(コンポーネント|component|サーバー|server|ブルーム|bloom)(?!`)/gi
 
-  - expected: Social
+  - expected: Relay
     pattern:
-      - /(?<!`)(Social)(?!`)/gi
+      - /(?<!`)(Relay|Social)(?!((-|\s)?VR))(?!`)/gi
+    specs:
+      - from: "`Social`"
+        to: "`Social`"
+      - from: Social
+        to: Relay
+      - from: Social-VR
+        to: Social-VR
+      - from: Social VR
+        to: Social VR
 
   - expected: Social-VR
     pattern:
@@ -87,12 +96,16 @@ rules:
 
   - expected: 電子署名
     pattern:
-      - /(?<!(電子))署名/g
+      - /(?<!(電子|公開鍵))(デジタル)?署名/g
     specs:
       - from: 署名
         to: 電子署名
       - from: 電子署名
         to: 電子署名
+      - from: デジタル署名
+        to: 電子署名
+      - from: 公開鍵署名
+        to: 公開鍵署名
 
   - expected: 公開鍵
     pattern:
@@ -101,6 +114,17 @@ rules:
       - from: 検証鍵
         to: 公開鍵
 
+  - expected: べき等性
+    pattern:
+      - /(べき|羃|冪|巾)(とう|等)性/
+    specs:
+      - from: 羃等性
+        to: べき等性
+      - from: 冪等性
+        to: べき等性
+      - from: べきとうせい
+        to: べきとうせい
+
   - expected: 秘密鍵
     pattern:
       - 署名鍵 

.textlintrc

@@ -1,6 +1,10 @@
 {
   "rules": {
-    "preset-ja-technical-writing": true,
+    "preset-ja-technical-writing": {
+      "no-exclamation-question-mark": {
+        "allowFullWidthQuestion": true,
+      },
+    },
     "period-in-list-item": true,
     "no-mixed-zenkaku-and-hankaku-alphabet": true,
     "ja-hiragana-hojodoushi": true,

gateway/README.md

@@ -1,4 +1,4 @@
-1. 全てのリクエストは羃等性があり、秘密鍵による電子署名を添付しなければならない
+1. 全てのリクエストはべき等性があり、秘密鍵による電子署名を添付しなければならない
 1. Gatewayコンポーネントが新設されるあるいは停止状態から復帰するとき、任意の他のGatewayコンポーネントを選択し全てのデータを受信できる
 1. Bloomの種類とエンドポイントと公開鍵を関連付けて保存できる
 1. Bloomの種類とエンドポイントと公開鍵の関連情報を検索、表示できる

sutera/01-significance-of-sutera's-existence.md

@@ -0,0 +1,62 @@
+# Suteraの存在意義について
+
+## 概要
+
+Suteraは分散型Social-VRを実現することにより、持続可能な仮想空間・メタバースの実現を目指します。
+**未来永劫Social-VRユーザーの居場所を保証・確約すること**、それが私たちの理念です。
+
+### Social-VRとは？
+
+VR空間上でアバターを通じたコミュニケーションができる、仮想空間やメタバースのことです。
+
+### 分散型ソーシャル・ネットワークとは？
+
+異なる運営者のサーバー同士が連合することによって、プラットフォームを分散・分権化されているソーシャル・ネットワークのことです。
+
+Suteraではこの仕組みをSocial-VRに応用し、リソースやコスト、リスクを分散することでプラットフォームの持続性を高めようとしています。
+
+### 既存Social-VRサービスは持続可能ではないのか？
+
+ユーザーが望む形でのサービスの持続について、不安になるような事例はいくつか挙げられます。
+
+- イーロン・マスク氏によるTwitter買収 (参考: [マスク氏に買収されツイッターは変わるのか](https://www.bbc.com/japanese/features-and-analysis-61227037))
+- VRChat社の大量解雇 (参考: https://x.com/VRChat/status/1801028372262248815)
+- Unity Runtime Feeの導入予告 (参考: [Unity騒動を受け、『テラリア』開発元が新鋭ゲームエンジン開発に多額の“太っ腹”寄付へ。新エンジンの成長を助けたいと明かす](https://automaton-media.com/articles/newsjp/20230920-265086/))
+
+Suteraはオープンソースプロジェクトであるため、ユーザーが望む形に沿ったSocial-VRを実現し続けることができます。
+また、誰でも自由にBloom(サーバー)を建てることができ、望ましいガバナンスを行使・享受できるでしょう。
+
+## 規格としての持続性
+
+Suteraは、仕様書であるこのドキュメントそのものが本体です。
+
+分散型Social-VRを実現するために必要な通信プロトコルやデータの規格について定義されています。  
+誰でも独自の実装を作成・公開でき、Suteraの規格にしたがっていれば異なる実装同士でも問題なく通信できます。
+
+## プラットフォームとしての持続性
+
+誰でもSuteraの仕様を実装したBloom(サーバー)を建てることができるため、Suteraネットワークは望まれる限り持続します。
+
+公式による実装としては以下のものを開発中です。
+- Bloom (サーバー): [SuteraVR/VanilaComponents](https://github.com/SuteraVR/VanilaComponents)
+- クライアント: [SuteraVR/VanilaClients](https://github.com/SuteraVR/VanilaClients)
+
+## データの持続性
+
+Suteraはプラットフォームだけでなく、アバターやユーザーなどのデータの持続性も実現します。
+
+詳細は「ユーザー依存データと非ユーザー依存データの違いについて」を参照してください。
+
+## FAQ
+
+### 既存のSocial-VRプラットフォームの打倒を目指しているのですか？
+
+**いいえ。**
+
+Suteraチームには、既存のプラットフォームで思い出を築いてきたメンバーが多くいます。  
+プロジェクトの方針としても個々のメンバーの感情論としてもそれらを打倒・否定することを目的とはしていません。
+
+分散型システムを採用することで特定の運営主体に依存しないSocial-VRプラットフォームを実現する。
+それにより既存プラットフォームが瓦解してしまったとしても**未来永劫Social-VRユーザーの居場所を保証・確約すること**を目的としています。
+
+

sutera/11-Why-sutera-need-to-maintain-idempotence.md

@@ -1,26 +1,27 @@
-# なぜSuteraネットワーク内の通信には羃等性が必要なのか
+# なぜSuteraネットワーク内の通信にはべき等性が必要なのか
 ## 概要 
 Suteraネットワークでは多くのコンポーネントが情報を保持・中継するうえ、認証を担う中央サーバーが存在しません。そのため、電子署名以外にリクエストの正当性を保つ手段をもちません。  
 しかし、まったく内容の同じリクエストならば電子署名を使い回すことが可能であり、リプレイ攻撃[^1]などが成立します。  
-Suteraネットワークでは、このような任意のタイミングで過去のメッセージが送信されることによる悪意ある攻撃に耐性を持つことが必要です。この耐性を確保するために、すべての通信仕様で冪等性を保つ必要があります。
+Suteraネットワークでは、このような任意のタイミングで過去のメッセージが送信されることによる悪意ある攻撃に耐性を持つことが必要です。この耐性を確保するために、すべての通信仕様でべき等性を保つ必要があります。
 
-## 冪等性とは
-情報工学において冪等性(べきとうせい、英: idempotence)とは、ある操作を一度行っても、複数回行っても同じ結果となることを指します。
+## べき等性とは
+情報工学においてべき等性(べきとうせい、英: idempotence)とは、ある操作を一度行っても、複数回行っても同じ結果となることを指します。
 特に何回実行しても内部状態が変わらない操作を指します。[^3]  
-冪等性の例として動画プレイヤーの一時停止ボタンを考えてみましょう。  
-ある動画プレイヤーに一時停止ボタンが有り、そのボタンを押すたびに一時停止と再生が切り替わると仮定します。この場合では、「一時停止ボタンを押す」という同じ操作を複数回行うたびに応内部状態が変わるため、冪等性はないと言えます。  
-次に一時停止ボタンと再生ボタンが分かれている場合を仮定します。この場合は一時停止ボタンを複数回押しても動画は停止したままであり、複数回同じ操作をしても内部状態が変わらない、すなわち冪等性が保たれていると言えます。
-## 冪等性がない場合
+べき等性の例として動画プレイヤーの一時停止ボタンを考えてみましょう。  
+ある動画プレイヤーに一時停止ボタンが有り、そのボタンを押すたびに一時停止と再生が切り替わると仮定します。この場合では、「一時停止ボタンを押す」という同じ操作を複数回行うたびに応内部状態が変わるため、べき等性はないと言えます。  
+次に一時停止ボタンと再生ボタンが分かれている場合を仮定します。この場合は一時停止ボタンを複数回押しても動画は停止したままであり、複数回同じ操作をしても内部状態が変わらない、すなわちべき等性が保たれていると言えます。
+## べき等性がない場合
 Suteraネットワーク内で頻繁に行われる「特定のユーザーが保持しているファイルの内容更新」を例に、リプレイ攻撃が有効となるような通信仕様を考えてみましょう。  
-以下の図は、冪等性がない場合の例です。この場合では最初にある人物Aが電子署名を付加したファイルを送信し、その後にAがそのファイルを更新して再び送信したと仮定します。
+以下の図は、べき等性がない場合の例です。この場合では最初にある人物Aが電子署名を付加したファイルを送信し、その後にAがそのファイルを更新して再び送信したと仮定します。
 ここで一番最初に送信した電子署名付きのファイルを悪意ある第三者が入手して、それを再送します。この場合、第三者が送信したファイルに付加されている電子署名は正常なものなのでサーバー側はこの更新を正常なものとして処理します。  
-このように、電子署名だけでは同じファイルの送信を複数回行っても正常に処理してしまうため冪等性がないと言えます。  
+このように、電子署名だけでは同じファイルの送信を複数回行っても正常に処理してしまうためべき等性がないと言えます。  
 ![figure of discription unidempotence](image/unidempotence.drawio.png)
 
-## 冪等性がある場合
-冪等性がある場合の例が以下の図です。Suteraネットワークでは冪等性を保つため、電子署名にバージョン情報を追加しています。  
+## べき等性がある場合
+べき等性がある場合の例が以下の図です。Suteraネットワークではべき等性を保つため、電子署名にバージョン情報を追加しています。  
 この例では先程の例と同様にある人物Aが電子署名を付加したファイルを送信し、その後に更新しています。しかし、この例では先程の例ではなかったバージョン情報が電子署名に追加されています。そのため、悪意のある第三者がリプレイ攻撃をしてもバージョン情報の整合性が取れず、サーバーでの処理が拒否されます。  
-このように、電子署名にバージョン情報を追加することで、同じ通信が複数回送信されても過去のバージョンに対する通信であることを認識でき、現在の状態を変更することはないため、冪等性が保たれていると言えます。
+このように、電子署名にバージョン情報を追加することで、同じ通信が複数回送信されても過去のバージョンに対する通信であることを認識できます。
+よって現在の状態を変更することはなく、べき等性が保たれていると言えます。
 ![figure of discription idepotence](image/idempotence.drawio.png)
 
 ## 参考文献、脚注

sutera/why-http.md

@@ -0,0 +1,21 @@
+# Sutera が HTTP にこだわる理由
+
+Sutera は管理コストやインフラコストを軽減するため、原則としてペイロードの小さい HTTP を基盤にプロトコルを設計しています。
+
+独自の通信プロトコルを使用するのはリアルタイム性が必要な最小限の部分のみと定めており、それに従って設計が進められています。（現在は [Clocking-Server](../clocking-server/clocking-server.md) でのみ独自の通信プロトコルを使用）
+
+HTTP にこだわる理由には、次のようなものがあります。
+
+- HTTP のみを使用できる代わりに、安価で簡単に構築できるマネージドサービス（クラウドなど）が多く存在する
+- HTTP はコストパフォーマンスに優れている
+- HTTP は1つのポートで複数のサービス（サーバーなど）を起動できる貴重なプロトコルである
+
+## HTTP がもたらす、Sutera への影響
+
+また、上記の利点により結果的に、Bloom 管理者がサーバーを立てやすくするなるという恩恵もあります。
+
+これにより、Bloom 管理者は Bloom をより簡単に建てることができるようになり、よりアクティブな Bloom が増えることによって Suteraネットワーク全体の安定性を高めることができます。
+
+Sutera はネットワークの安定性を高めるためにもサーバーを建てやすくする必要があると考えています。
+
+これによって、Sutera では原則として HTTP を基盤とし、必要な部分のみを独自の通信プロトコルで実装するという決定をしています。