参考：
invite_code という新しいオプション設定が追加されました。
この設定が有効な場合、アカウント登録を行うすべてのユーザーは、招待コードを入力する必要があります。招待コードがないユーザーはアカウントを登録できません。
招待コードが誤っている場合、ユーザーには役立つエラーメッセージが表示されます。
この機能は完全にオプションです。現時点ではローカル認証との互換性のみ対応していますが、今後のバージョンで改善予定です。
グローバルな招待コードを有効にすると適用されますが、無効な場合は適用されず、登録ダイアログに招待コードは表示されません。
これはどうして理にかなっているのですか？コードはスタッフによる新規アカウントの承認を回避できるようにするべきではありませんか？
このコードはスタッフか非スタッフかに関するものではなく、100% 新しいアカウントの登録に関するものです。
ユースケースは、WhatsApp または Facebook の非公開グループへの投稿です。
こんにちは、あなたのためにフォーラムをセットアップしました。アカウントを登録するには招待コード「Welcome to Discourse」を使用してください。
サイトは登録のみを必要とするため、コードを持っている人のみがアクセスできます。
もちろんこれを拡張することは可能ですが、私はこの機能について超緊急のユースケースを持っていたため、今日中にこれを完了させ、来週に洗練させる予定です。
このユースケースが全く理解できません。
新しいアカウントの承認を有効にして、人々をそのサイトへ誘導するのはどうでしょうか？
これには各アカウントの手動モデレーションが必要です。この設定は、少数のユーザーでテストを行いたい方や、フォーラムアクセスを特典とするプロモーションを実施している方にとって非常に役立ちます。このような招待コードは、パイロットプロジェクトのフォーラムの作業負担を劇的に軽減します。
すべてのメールを承認し、24時間365日承認キューに待機しなければならないからです。また、登録したのが単なるランダムなボットなのか、実際にアクセス権を持つべき人物なのか、全く判断できません。
招待コードがあれば、少なくとも私が非公開で共有した招待コードを持っていることは確実です。
でも、ユーザー承認の「すべて」の目的はそれでは？
COVID-19 対応プラットフォームの支援にもなります。はい、ぜひ、至急!!!
この機能に +1 です。私が運営しているいくつかのコミュニティにとって、これは非常に有用です。上記の @codinghorror と @ondrej の「手動承認」に関するご指摘は理解していますが、これは「招待のみ」のサイトと「ユーザー承認」のサイトとの間に存在するギャップを埋めるものだと考えます。
ユーザーの承認は行いたくありません。Slack、Telegram、WhatsApp グループにコードを投稿し、誰もがそれを利用できるようにするだけです。正式なローンチ前に数人の追加テスターがいても、あまり問題はありません。
はい、この機能は現在、非常に役立つでしょう！
これとても役立ちますね。特に、機能を少し拡張して、特定の招待コードに「グループを紐付ける」ことが可能になれば、そのコードを使ってアカウントを作成したユーザーが自動的に特定のグループに追加されるようになります。
いくつかのユースケースでは、これにより、時々話題になる「メールアドレスに依存しない招待トークン」の要望も解決できるかもしれません。
これは、
少なくとも私が個人的に共有した URL が存在していた
という点と、実質的にどのように異なるのでしょうか？
正直なところ、現在の仕組みではこの機能の意図が全く理解できません。
ここには、バイパスコードの入力または管理者の承認というオプションのどちらかを選べるようにするのが最も理にかなっています。
私はこの形式を少し変えたものが好きです。少し調整が必要です。もし今すぐそれが必要（？）なら、まあいいでしょう。
ただ、個人的には、マジックドメイン…
https://forum.this-is-my-magic-domain.orgでサインアップしてください
という仕組みが、マジックパスワード…
このサイトにアクセスするには秘密の
this-is-my-magic-passwordを知る必要があります
という仕組みよりも、全く使えず、全く機能しないレベルの登録保護だとは思いません。
これには2つの形式があり、どちらも喜んでサポートします。
amazing.forum.comにアクセスし、招待コードfantasticを入力してアクセス権を取得してください（実装済み）
そして
amazing.forum.com/register?code=fantasticにアクセスして登録し、フォーラムへのアクセス権を取得してください
一般的にこの問題を解決する方法として、サイトを HTTP ベーシック認証の背後に置くというやり方を採用しているため、おそらく「100の法則」を超えているでしょう。
どちらも非常に似ていますが、現時点では #1 を実装し、その後 #2 も追って実装する予定です。
#1 の利点は、コピー＆ペーストに依存しない場合でも扱いやすいことです。例えば、WhatsApp で指示を受け取り、その後デスクトップで完了させるような場合です。
#2 の利点は、fantastic の入力回数が減ることと、「メール」での共有に対して WhatsApp での共有よりも便利である点です。
forum.this-magic-domain.org がどこから来たのか不明ですか？どちらの場合も、これはフォーラムが置かれているのと同じドメインです。
これの UI がどうなるかと思った、簡単なモックアップです。
（これは、メール認証後に must_approve_users が有効な開発サイトでの表示です）
サインアップ時および承認されていない状態でのログイン時にオプションであるべきです。なぜなら、すべてのユーザーがコードをコピーして転送することを義務付ける仕組みは、破綻し、管理者の介入が必要になるからです。
いいえ、確実に漏洩します。https://www.farsightsecurity.com/technical/passive-dns/passive-dns-faq/#q11
これは時間制限付きのセットアップでは機能しますが、長期的な対策としては機能しません。
アカウントを作成した後に、なぜ承認コードが必要なのでしょうか。
つまり、ボットは意味のないアカウントを登録するだけで、データベースを汚染するずっと前に排除できるということでしょうか？
さらに、アカウントはすでに登録されており、すでに検証済みかもしれません。
それに、いったいどこから「秘密のドメイン」についてのこの議論が出てきたのでしょうか。
もしこれを Meta で有効にしたとしましょう。例えば：
meta.discourse.org にアクセスし、HELLOMETA というコードを入力してアカウントを作成してください。
今になって気づいたのですが、私は前のトピックで @codinghorror さんのポイントを誤って繰り返し述べてしまいました。（これは #feature:announcements にあったため、執筆時には読んでいませんでした）
要するに、これは全く別の並行システムを作るのではなく、must_approve_users と login_required の上に構築されるべきです。現在の実装は、現在の危機を乗り切るためのハックとしては問題ありませんが、修正が必要です。
会議で提示すると、誰かがコードを忘れたり、書き留めなかったりする可能性があります。あるいは、会議の動画が公開された後にコードをローテーションする必要があります。コードをサインアップフォームに正しくコピーさせるように促すよりも、WhatsApp グループで「@test3 のアカウントは誰のものですか？」と聞き、肯定の回答を得て、
をクリックする方がはるかに良いです。（注：これらのスクリーンショットはメール認証後のものです。）
問題ないと思います。最終的な調整が必要なだけです。ここには私が完全に支持する改善点がいくつかあります。
まず、ユーザー招待ページとの統合です。例えば、https://meta.discourse.org/signup?u=codinghorror というリンクにアクセスしてメタに登録した場合、私のユーザープロフィールページには「私が招待した人」として表示されます。以下のようになります：
メールベースの招待は、招待されたユーザーにすでに TL1 を付与していることを思い出してください。つまり、この特典は既に備わっています。招待ダイアログを確認してみてください。グループアクセスの追加もでき、TL の引き上げも暗黙的に適用されます。実際、このダイアログのテキストではこれを明確に説明すべきでしょう：
次に、上記 
にあるように、メールアドレスなしで招待リンクを生成できるようにすべきです。これは「でも相手のメールアドレスがわからない 
」という問題を完全に解決します。
第三に、サイトが「招待制」であり、招待がすべてハイパーリンクと秘密のパスワードの形式であることは問題ないと思います。そうすれば、
open sesame）という組み合わせになります。
また、サイトに承認機能がある場合、秘密のパスワードを使えば承認をスキップできます。承認機能がない場合でも、秘密のパスワードがなければ入ることができません。
私の主な懸念は、既存の機能と統合されていない点です。むしろ、不明瞭なサイト設定を通じて何らかの機能を無理やり追加しているように見えます。しかし、統合することで、招待機能をより優れたものにし、奇妙なスタンドアロンのサイト設定にするのではなく、改善できるはずです。