登録とアカウント
なぜログイン名とパスワードが不要なのですか?
登録時、アプリはサーバーから暗号学的な Proof of Work チャレンジを受け取り、それを解きます——これによりボットによる自動登録を防ぎます。同時にデバイス上で、一意のデバイス識別子と複数の暗号鍵セットが生成されます:長期アイデンティティ鍵、署名済み事前鍵、およびワンタイム事前鍵(ポスト量子 ML-KEM-1024 鍵を含む)。サーバーに送られるのはこれらの鍵の公開部分と PoW の結果だけです。秘密鍵がデバイスを離れることはありません。パスワードはありません。アカウントは鍵で定義され、12語の復旧キーで新しいデバイスに戻せます。
ログアウトして再ログインできますか?
はい、12語の復旧キーがあれば可能です。新しいデバイスや再インストール後に「復元」を選び、単語を入力してください。アカウントとそのアドレスが戻ります。過去のメッセージとセッションは元のデバイスに残り、移りません。この単語がなければ、デバイスの紛失やアプリの削除はアカウントの永久的な喪失になります。
スマホを乗り換えてもアカウントを失わないには?
復旧キーは登録時に自動で作られます——何もする必要はありません。その控え(12語)は後から設定で保存できます。アプリが通知し、サインアウトの前には必ず求めます。控えを作るまで、単語は暗号化されてデバイスに保管され、Face ID・指紋・端末のパスコードの後にだけ開きます。控えを作ると、デバイスから消去されます。書き留めて安全な場所に保管してください——Konstruct はあなたの電話番号もメールも持たないため、これがアカウントに戻る唯一の方法です。
連絡先
誰かにメッセージを送るには?
見知らぬ人がいきなりあなたに書き込むことはできない設計です。会話を始めるには、一方が QRコードか招待リンクを共有し、もう一方がそれを読み取るか開きます。これらは使い捨てです。QRコードは5分、リンクは12時間で期限切れになります——一度受理されたリンクは再び受理できません。別途、設定で発見可能性を有効にすればユーザー名で見つけてもらえますが、既定ではオフなので、有効にするまでは招待だけが入口です。
なぜこの制限があるのですか?これでは不便ではありませんか?
意図的な設計です。多くのメッセンジャーでは電話番号やユーザー名を知っていればメッセージを浴びせかけられます。ここでは相互同意がアーキテクチャに組み込まれており——プライバシーポリシーに書かれているだけではありません。
自分の許可なく QRコードを共有されたらどうなりますか?
コードを受理できるのは一度だけなので、共有されたリンクで入れるのは最大で一人です。すでに使用済みのリンクは何もしません。またリンクは作成から12時間、QRコードは5分で無効になります。それでも誰かが入ってきた場合、新しい会話が表示されるので、すぐにブロックできます。
暗号化とプライバシー
暗号化はどのように機能しますか?
すべてのメッセージは送信前に送信者のデバイスで暗号化され、受信者のデバイスでのみ復号できます。サーバーが見るのは暗号化されたストリームだけで、それをルーティングします——内容を読むことはできません。鍵確立にはポスト量子鍵合意で拡張した X3DH(PQXDH)を使います:送信者が受信者の Kyber プリキーへ ML-KEM-1024 の秘密をカプセル化し、その秘密は古典的な鍵と一緒にセッションの初期鍵に入ります。これが「今記録して後で量子コンピュータで復号する」を制限します。ポスト量子の保護は最初のメッセージから有効で、それなしではアプリはセッションを確立しません。以降は Double Ratchet がメッセージごとに鍵を回転させ、各メッセージには固有のポスト量子鍵もあるため、1つの鍵が漏洩しても過去・未来のメッセージは露出しません。誰が送ったかもポスト量子で守られ、通話は双方のアプリが対応していればポスト量子 DTLS を使います。まだ古典的なもの:サーバーの署名(送信者証明書、鍵透明性ログ)、デバイスのサインインとアカウント復旧、Privacy Pass トークン、トランスポートの TLS。グループはまだありません。完全な一覧はプロトコル仕様にあります。
サーバーは正確に何を見ていますか?
ごくわずかで、そのどれもあなた自身ではありません。メッセージを配送するためにサーバーが必要とするのは、受信者の不透明なアカウント ID、暗号文のサイズ、到着時刻です。加えて公開鍵と、iOS ではプッシュトークンを保持します。以上がすべてです。内容も、名前も、アバターも、連絡先一覧も見えません——常時有効な送信者の匿名性(sealed sender)により、誰が送ったかも見えません。メッセージは暗号文としてのみ保持され、配送時ではなく保存期限(約7日)で削除されます。ユーザー名は任意で、ルーティングには使われず、鍵付きハッシュとしてのみ、人があなたを見つけられるようにする目的だけで保存されます。その検索も、発見可能設定を有効にするまで無効です。つまり既定では、ユーザー名でアカウントを見つけることはまったくできません。
メタデータは?誰が誰と話しているか?
こちらはより難しい部分です。サーバーは依然として誰かがデバイス B へ暗号文を届けたこと(受信者、時刻、サイズ)を観測できます。常時有効の 送信者の匿名性により、誰が書いたかは分かりません——次の質問を参照してください。検閲対策はネットワーク経路を部分的に隠します。ルーティング層での完全な匿名性(受信者側からも、ネットワークレベルの IP・タイミング相関からも隠れること)は桁違いに難しい問題で、現時点では解決されていません。
サーバーは誰がメッセージを送ったか分かりますか?
いいえ——送信者フィールドは封筒に入れません。これは通常のトラフィック(メッセージ、配信レシート、通話の確立、プロフィール共有)で常に有効で、切り忘れるスイッチはありません。端末は署名済みの送信者証明書を受信者の鍵で封緘します。受信者はそれを開いて誰が書いたか検証できますが、サーバーにはできません。いくつかの内部経路——接続維持、自分の端末間の同期、セッションの保守——は設計上、送信者を持ち続けます。
何が隠されているのかは正確に言う価値があります。それは身元ではないからです。サーバーはそもそも身元を持っていません:ここでのアカウントは鍵ペアと不透明な ID であり、電話番号もメールも本名も紐づいていないので、人物と結びつけるものが最初から存在しません。送信者の匿名性が取り除くのは、そうした ID 同士の最後のつながり——誰が誰に書いたか——です。ネットワーク層は別の話で、上に書いたとおり、時刻と IP は見えたままです。
制限事項:送信者の匿名性がサーバーから隠すのは送信者の身元であり、メッセージの時刻、サイズ、IP アドレスではありません——これらはネットワーク/トランスポート層で見えたままです。スパム対策として Privacy Pass トークンを 送信者を伏せた送信に添えることができます。サーバー側での強制適用は展開中で、トークンによるレート制御は成熟途上であり、完成してはいません。
分析やテレメトリを収集していますか?
いいえ——一切ありません。分析も、利用メトリクスも、行動イベントも、クラッシュの自動送信も、広告識別子もありません。「収集して匿名化」ではなく——そもそも収集しません。アプリにサードパーティトラッカーはなく(Firebase、Crashlytics、Sentry、Amplitude、Segment なし)。外部依存はトランスポート/メディア基盤と、iOS ではオンデバイスの音声認識ライブラリだけです。リリースビルドは診断ログをディスクに書きませんし、デバッグやログエクスポート画面もありません。バグ修正にログが必要なときは、ベータビルドであなたが「共有」をタップするだけ——無言のアップロードは決してありません。
プロフィール
Display Name は何のためですか?
表示名とアバターは端末上にあります。公開プロフィールの一部ではなく、誰も検索できません。新しい会話を始めると、相手に見えるのは生成された仮名だけです——同じ ID からは常に同じ名前が生成されます。本名と写真を見せるには、相手のプロフィールを開いて「アイデンティティ情報を共有」をオンにします。どちらも暗号化されたチャネルを通ります。例外が1つ:連絡先リクエストを送ると、誰が申請しているか受信者に分かるよう、ユーザー名と表示名が添付されます。サーバーはそのスナップショットを保存時に暗号化しますが、鍵はサーバー自身が持ちます——エンドツーエンド暗号化ではありません。アバターが含まれることはありません。
なぜ空白ではなく生成名なのですか?
空白の名前は使いにくいです——チャット一覧に特徴のない行が並び、連絡先を区別できません。生成名は安定しています:その ID ではどのデバイスでも「Quick Falcon」は常に「Quick Falcon」です。
相手にユーザー名がある場合、見えますか?
はい。表示の優先順位:Display Name(共有された場合)→ ユーザー名 → 生成名。そのため @john で登録した人なら「Peaceful Whale」ではなくその名前が見えます。
メッセージ
配信ステータス表示は何を意味しますか?
- 送信中 端末上で暗号化中です
- 送信済み 端末を離れ、サーバーが受け取りました
- 配信済み 受信者の端末が復号し、確認を返しました
- 送信待ち まだ送信されていません——アプリが自動的に再試行します。待ちたくなければタップしてください
- 送信できませんでした 再試行では解決しない理由で拒否されたため、自動では何も起きません。タップで再試行してください
「既読」ステータスはありません。意図的です:既読通知は、あなたがいつアプリを開いたかを送信者に伝えてしまいます——メッセージには不要な、あなたについての事実です。「配信済み」は受信者の端末からの暗号化されたレシートであり、サーバーが転送したという通知ではありません。
送信済みメッセージを編集できますか?
はい、編集はサポートされています。変更後、メッセージには「編集済み」と表示されます。編集内容は通常のメッセージと同じ配信メカニズムで受信者のデバイスに届きます。
アプリを閉じているときに、通知が届かないことがあるのはなぜですか?
iOS では通知は Apple Push Notification Service(APNs)経由で届きます。安定した接続が必要で、機内モード、強いフィルタリングの VPN 配下、または Apple がプッシュを「低優先度」と判断した場合は、遅れるか届かないことがあります。Android にはプッシュサービスが一切ありません。アプリは独自の接続を保ち、常駐通知でそれを示します。強いバッテリー節約やネットワークの遮断でメッセージが遅れることがあります。アプリを再び開くと、メッセージは自動で同期されます。
検閲対策
メッセンジャーが遮断されている場所で Konstruct は使えますか?
直接接続が遮断されたときに、アプリのネットワークへの到達方法を変える検閲対策モードがあります。設定では「オフ/自動/オン」の3段階のスイッチ1つで、既定は「自動」です:直接接続が機能している間はそれを使い、失敗が確認されたときにのみ切り替えます。設定する項目も入力するアドレスもなく、準備はバックグラウンドで行われます。実装はオープンソースなので、設計は誰でも検証できます。
検閲対策は常に有効ですか?
既定は自動です——直接接続の方が速いため、機能している間はそれを使い、明確に失敗したときにのみ切り替えます。強制的にオン/オフにすることもできます。私たちが意図的に公開しないのは、どの技術が現在稼働していて、どこで今それが通っている/通っていないかです。公開された最新の状況報告は、遮断する側にとって無償のフィードバックになります。同じ理由で、アプリ自身もそれを表示しません。
ネットワーク耐性と持続可能性
Konstruct のサーバーがオフラインになったらどうなりますか?
サーバーが戻るまでメッセージのやり取りは止まります。アルファは信頼サーバー1台で動いており、現時点では第二の経路がありません——リレーも、端末間の直接接続も、頼れる別のノードもありません。暗号化されたものは暗号化されたままで、失われはしません。ただ動かないだけです。ロードマップはまさにこれを覆すためにあり、まだ何も公開されていません。
基本的なメッセージングは常に無料ですか?
はい——無条件に。メッセージの送受信、E2EE、すべてのセキュリティ機能がペイウォールの向こうに回ることはありません。寄付のみのモデルはプライバシープロジェクトでは歴史的に脆弱だったため、Konstruct は組み合わせを計画しています:任意の寄付、オプションのプレミアム機能(大容量ファイル転送、拡張履歴、カスタムテーマ——セキュリティ機能は決して対象外)、組織向け B2B ホストインスタンス。コアは常に無料です。
Konstruct の資金源は?寄付できますか?
広告なし、データ転売なし、テレメトリなし——その代わりに Konstruct は任意の寄付で運営されています。寄付は開発とサーバーに直接充てられます。プライバシーを重視するならMonero (XMR)を推奨します——Bitcoin と違いブロックチェーンが公開されていません。ページ改ざんに備え、送金前に必ずプロジェクトリポジトリとアドレスを照合してください。
- Monero (XMR) — 推奨:
496i5qvPzRtJPQjiPXnLvEGutjHFth4pWDQaJwbbMreyaTYg4qfbo48MXrTnYH32MHiAn5GcSEN1c48EYBvVkrx9Pi5BWvn - Bitcoin (BTC):
bc1q5cthgu6k9utg9hk2mx2xshdtsrhvu54ysmqhmm - Ko-fi — 手軽ですが匿名ではありません。決済事業者があなたの身元を知ります:
ko-fi.com/construct_msg
P2P モードとは何で、いつ有効になりますか?
P2P モードは計画段階で、まだ実装されていません——現在すべてのトラフィックは中央サーバーを経由します。目標とする設計:両者が同時にオンラインで Konstruct サーバーに接続しているとき、サーバーが直接の P2P QUIC 接続へ移行するよう合図します。確立後、サーバーはメッセージ中継経路から抜け、トラフィックはデバイス間を直接流れます。どちらかがオフラインになれば、配信はサーバー経由に戻ります。
セキュリティと保護
見知らぬ人から大量にメッセージが来たら?
そのためにアプリには ロックダウン・モードがあります。有効にすると、有効化時点で連絡先にいた人からのみ通知が届きます。新しい送信者からのメッセージは保存されますが——邪魔はしません。公人で新しい連絡先から一時的に遮断したいときに有用です。
特定の一人が数百通スパムしてきたら?
短時間に同一送信者から不審に多いメッセージが届くと(30 秒で約 10 通超)、クライアントは自動で警告を出し、その人からの通知をミュートします。その後、許可するかブロックするかを選べます。重要な点:これは受信側の保護であり、送信者がどのクライアントを使っていても機能します。
技術的な質問
「セッション」とは何で、なぜ時々「壊れる」のですか?
セッションは二台のデバイス間に確立された暗号化チャネルです。再利用できないワンタイム鍵の上に構築され、メッセージごとに鍵が回転します。アプリが長時間非アクティブだった、デバイスを再インストールした、相手がチャットを削除した——こうした場合、届いたメッセージが読めないことがあります。そのとき受信側のアプリは、そのメッセージがどのセッション状態で書かれたかを送信側に知らせ、送信側のアプリは新しい状態を開いてメッセージを送り直します。通常ユーザーは何も気づかず——メッセージはそのまま届きます。
複数デバイスはサポートされていますか?
公開ビルドではまだ2台目のデバイスをリンクできません。ネイティブのデスクトップクライアントは開発凍結中で、ターミナル(TUI)クライアントを開発中です。アイデンティティがサーバーアカウントではなく鍵に紐づくため、マルチデバイス対応には別の鍵バインディング機構が必要です——現在作業中です。
ライブメッセージに Konstruct はどのトランスポートを使いますか?
ライブメッセージングは gRPC 双方向 MessageStream です——ハートビート、受信メッセージ、配信レシートを1本の長寿命ストリームで運び、リクエスト/レスポンスのポーリングは行いません。現行の iOS ビルドの本番経路は QUIC(construct-transport)で、QUIC が遮断されるかハンドシェイクが失敗すると、自動的に HTTP/2 + TLS 1.3 上の gRPC にフォールバックします。エンドツーエンド暗号化はトランスポートから独立しています:回線を流れるのは封緘された暗号文だけです。
テスター向け
最初に何を確認すべきですか?
- 登録と QR コードによる連絡先の追加
- メッセージの送受信(双方向)
- 配信ステータス——「配信済み」まで到達するか、「送信待ち」「送信できませんでした」はタップで再試行されるか
- メッセージの編集——受信者に変更が見えるか
- アプリがバックグラウンドのときの通知
- 接続が悪い状況での挙動(機内モード → 復帰)
- 再インストール後の復旧キーによるアカウントの復元
- 設定からの復旧キーの控えの保存
バグの報告方法は?
診断(内部)ビルドでは、設定 → 診断とログ → ログを共有 です。公開ビルドはログを保持せず、その画面をコンパイルすらしません——その行がないビルドなら、状況を説明してください。診断ビルドをお渡しします。説明が正確なほど(何をして、何を期待し、何が起きたか)調査は速くなります。セッションの問題では、両方の端末のログを添えてください。
ログに繰り返し行が多いのはなぜですか?
デバッグビルドでは、UI が更新されるたびにログを書くコンポーネントがあります——開発中は正常です。FRC updated: 69 message(s) in window のような行はチャット一覧の更新で、問題を示すものではありません。