bitcoincashresearch.org では、フォーラムの一定レベルの分散化を実現しようとしており、必要と考える誰もが別のドメインでフォーラムのインスタンスを再構築できる可能性を含めています。
そのためには、定期的にデータベースのバックアップを公開する必要があります。しかし、メールアドレスや IP アドレスなどのユーザーの個人情報を露出させるという問題に直面しています。
これらの個人情報を手動でデータベースのバックアップから削除することも可能ですが、定期的なバックアップを考えると、最も賢明でクリーンな選択肢とは言い難いでしょう。
これに関連して機能する解決策をご存知でしょうか？あるいは、同様の事例をご存じでしょうか？
それはかなり奇妙なエッジケースですね！
IP アドレスとメールアドレスを削除したいとお考えですか？メールアドレスがなければ、ユーザーがアカウントを復元する方法がなくなります（パスワードを使用している場合はログインできますが、変更を検証する方法がないため、メールアドレスを再度登録することはできません）。
少なくともメールアドレスを含まない実用的なバックアップを作成する方法は考えられません。
Discourse フォーラムの公開 SQL ダンプはこちらです：Index: if-archive/info/intficforum
そこからいくつかアイデアを得ることができます。
それは奇妙な特殊事例に見えるかもしれないと同意します。しかし、その背後にある考え方は、フォーラムの中央集権化を防ぐ方向に働くため、それほど不自然なものではありません。
このことが一部のフォーラムにとっては重要ではないかもしれないことは理解していますが、他のフォーラムにとっては重要かもしれません。
また、バックアップからユーザーやパスワード（その他情報）を削除すると、それらのユーザーが新しいインスタンスにログインできなくなる点にも同意します。
だからこそ、それが最も賢明な方法ではないと言ったのです。
おそらく、私の質問を言い換えるべきでしょう。
ユーザーの個人情報を晒すことなく、誰でも特定のフォーラムのインスタンスを再構築できるようにデータベースのバックアップを公開するための既知の方法や推奨手順はありますか？
いくつかの文脈を追加させてください。非常に特定のニーズやユースケースがあります。
重要なコンテンツを含む運用上の議論があり、そのコンテンツは時間とともに重要性を増していきます。これを利用するエコシステムの性質上、単一障害点を避けることが非常に重要であることがわかってきました。
現在のエクスポート機能では、認証情報を除外すれば、サイト全体のコンテンツを公開することが可能ですが、@pfaffman が指摘した通り、ユーザーが認証できなくなり、エクスポートされたサイトが読み取り専用になるという取り返しのつかない分断が生じてしまいます。
したがって、Leandro が必要としているのは、従来のアカウント/パスワード方式ではなく、暗号学的なチャレンジを通じてユーザーがログインできる Discourse の機能だと考えます。そして、エクスポート時には、アカウント情報のうちその部分のみを含め、他のメールやパスワードハッシュなどは含めないようにします。サイトの別コピーでは、この機能を利用したユーザーがログインし、メールや標準的なアカウント復元手順を経てアクセスできるようになります。
このような完全な公開を行う際には、メールやパスワードハッシュなどの従来のアカウント認証情報を一切含めないことが極めて重要です。この機能が実装された Discourse のどのバージョンにおいても、機密情報はサイトデータの残りの部分とは別の場所に保持され、誤ってエクスポートすることが不可能になるようにする必要があります。
これが、少し考える材料となる文脈の追加になれば幸いです。
また、これらの変更は明らかに非常に複雑です。フィードバック、課題、代替案をお聞かせいただければ幸いです。もしかすると、エコシステム側でリソースを結集して、このアイデアを実装するフォークを作成できるかもしれません。
これは、WebAuthn サポートで説明されているように、パスワードレス認証方法として WebAuthn のサポートを追加することで実現できます。
さらに、公開したくないフィールドを含むバックアップファイルをクリーンアップするサービスも必要です。
それはログインの別の解決策です。
ちなみに、ログイン中の通常ユーザーはメールアドレスの変更を承認する必要はありません。したがって、メールアドレスを削除したダンプは、データベース内の認証情報（パスワードが最も簡単です）を使ってログインすべきすべてのユーザーにとって問題ありません。
メールアドレスを削除するか、暗号化するプラグイン（それなりの容易さでそれを行う方法がわかっていると思います）が問題を解決します。
私が開発したプラグインでは、以下のように一部のフィールドを暗号化しています。
同様に UserEmail モデルを上書きしてメールアドレスを暗号化できるのではないかと考えています。UserEmail モデルにはコードがほとんどなく、頻繁に変更されることもないと思われるため、それほど危険な変更ではないかもしれません。あるいは、全く機能しない可能性もあります。
IP アドレスをフィルタリングするのはもう少し難しいかもしれません。ユーザーモデルを上書きするのは難しいと思うからです。その場合、IP アドレスを何らかの方法で削除するプラグインを作成するとよいでしょう。
@Falco さん、@pfaffman さん、フィードバックとアドバイスありがとうございます。
WebAuthn を調査して、その方向に進めるかどうかを確認します。また、@pfaffman さんのプラグインについても同様に検討します。
数日中に、コメントや質問、結論などをお伝えします。
もう一つの可能性として、パスワード認証鍵交換（PAKE）の強化版の利用が挙げられます。これにより、パスワードはデータベースから事実上復元不可能となり、かつ通信経路を通過することもなくなります。
残念ながら、これらはいずれもまだ実験的暗号の領域にあり、容易な導入には至っていません。iOS の iCloud 同期では PAKE が採用されています。
メールとパスワードによるログインを維持しつつ、バックアップされたデータベース内の任意のユーザーのアカウントに誰でもアクセスできるようにしたい場合は、すべてのユーザーに対してユーザー名に基づいたメールアドレス（例：<username>@email.invalid）を生成することで実現できます。
パスワードとログインについては、Discourse がソルト付きの暗号化パスワードを使用しているものと仮定します（確認はしていませんが、おそらくそうでしょう）。ライブデータベースで 123456 というパスワードを設定し、データベース上でその結果として得られる暗号化パスワードとソルトを確認します（その後、パスワードを元に戻すか、ダミーのアカウントで行ってください）。次に、新しい（クローンされた）データベースで、すべてのユーザーの暗号化パスワードとソルトを、先ほど確認した値に設定するコマンドを実行します。これにより、すべてのユーザーが同じ暗号化パスワードとソルト（つまり、同じパスワード）を持つことになります。したがって、ユーザー foo の場合、メールアドレス foo@email.invalid とパスワード 123456 でログインできるようになります。
それ以外には、機密データが含まれている可能性があるため、不要であればプライベートメッセージを削除することをお勧めします。
最後に、(管理者) 設定など、機密データが含まれている可能性のあるフィールドも確認しておくのが良いでしょう。