Discourse あちこちで見かけるようになり、とても嬉しいです！コミュニティが新しいディスカッションフォーラムを素早く立ち上げたり、古いプラットフォームや時代遅れの UX パターンに基づく既存のフォーラムを置き換えたりする際の標準的な選択肢として、急速に定着しているように思えます。
しかし、ある意味では成功の犠牲になっているようにも感じます。新しい Discourse コミュニティに投稿するたびに、アカウントを作成し、パスワードを設定するなどの手続きが必要になるからです。一部のコミュニティは GitHub や SNS などを介した OAuth の設定を済ませていますが、多くのコミュニティではまだ行われていません。1 つの質問をする、回答を提供する、あるいは役に立った回答に❤️をつけるだけでも、それぞれの Discourse サーバーで新しいアカウントを作成して認証しなければなりません。
これと比較して、StackExchange ネットワークでの私の経験では、初めて関わりを持つコミュニティに対して「このコミュニティに参加」ボタンが表示されます。このボタンをクリックすると、他のコミュニティのログイン情報を使ってサインアップするオプションが提示されます。
新しいアカウントがワンクリックで自動的に作成され、ログインされます。
私の課題は、各 Discourse コミュニティが独自の島嶼として存在し、ユーザーは 1 つのフォーラムに常時ログインして、レスポンスや新しい質問を待ちながら、バッジを獲得したり権限を積み重ねたりして楽しんでいるという、明言されていない前提がある点だと考えています。実際には、ユーザーの大半の関わりは必要性に駆られたものであり、定期的にコミュニティに参加して支えているのはごく少数のユーザーに過ぎません。一般的なユーザーの Discourse コミュニティとの関わりは、以下のような流れだと考えられます。
- 問題に直面する
- Google で答えを探す
- グループの Discourse フォーラムを含むインターネット全体で解決策が見つからない
- 問題が切迫しているため、フォーラムにアカウントを作成することを決意する
- 質問を投稿するか、既存の質問にコメントする
- 誰かから回答を得るか、最終的に自分で解決策を見つける
- 自分で解決し、かつ他者への貢献意欲があれば、Discourse フォーラムに解決策を報告する
- 日常生活に戻る
- 数年後に別の問題に直面し、フォーラムに再度ログインするために資格情報を思い出そうとする
- 手順 5〜10 を繰り返す
このプロセスの多くは、参加したい新しいフォーラムごとに新しいアカウントを作成しなければならないことにより、妨げられています。
StackExchange コミュニティは中央の企業が管理しているのに対し、Discourse コミュニティは完全に分散された方法でホストされていることは理解しています。しかし、Discourse 自身がアイデンティティプロバイダーサービスを提供することで、この課題を解決できるはずです。GitHub や Facebook などの外部サービスとの連携では、フォーラムの管理者が外部サイトで OAuth の設定を行うなどの積極的な手順が必要ですが、「Discourse でログイン」ボタンのための必要なトークンは、標準的なインストールプロセスを通じて自動的に設定可能だと考えられます。
この問題については 他の議論 も存在しますが、それらは範囲が過度に複雑で、本題から逸れてしまっているように見えます。
「いいね！」 2
sunjam
(james.network)
2
これは異なる種類のフェデレーションであり、投稿や返信（ログインとは対照的）に関連して Discourse を Mastodon などのツールに接続するものです。
メタの様々なトピックで議論されている Discourse SSO を確認することをお勧めします。
「いいね！」 1
david
(David Taylor)
3
ご指摘の件は、Discourse 誕生当初に多く議論されました。それに関連するタグとして #discourse_hub があります。
最新のトピックは 2014 年のものです：
（ちなみに、Jeff が例として @david という名前を使っているのを今気づきました。私が Discourse の存在を知ってから何年も前のことですね 
）
とても素晴らしいアイデアですが、実現には多くの障壁があります。
「いいね！」 6
素晴らしい、ありがとうございます！そのスレッドで説明されていた多くの問題は、過去6年ほどでSEが解決したようです（例えば、ユーザーの一意な識別子として「番号＋ユーザー名」を使用するなど）。
問題の核心は、SEとは異なり、Discourseは分散型であり、各コミュニティはそれをホストするサーバーを管理する人が完全に制御している点にあるようです。また、コミュニティのアクセシビリティ向上のために多少の管理権限を譲りたくない管理者向けに、Discourse Hubへの参加をオプトアウトする選択肢を設けることもできるはずです。その代わり、アクセシビリティやユーザーエンゲージメントが低下するというコストが生じることは理解しておく必要があります。
Falco
(Falco)
5
DiscourseHub」プロバイダーに対して、デフォルトで有効化されたソーシャルログインを標準搭載し、ユーザー名、氏名、メール、アバター、自己紹介といったすべてのデフォルトフィールドを完全にサポートするなどの機能を提供することも可能です。さらに、双方向の同期も実現できます。例えば、新たに作成されたユーザーアカウントから情報を取得し、バッジや最高評価の投稿などの詳細を中央プロフィールに公開することもできます。また、パスワードの最低文字数を大きく設定したり、二要素認証（2FA）を必須化したりするなど、ベストプラクティスの普及を推進するのにも活用できます。
ただし、これを「実施すべきか」については、まだ大きな未解決の課題です。
「いいね！」 3
この問題のどれくらいが、（私たちによって）中央集権的に管理されるディレクトリによって解決されるでしょうか？
それでも、各サイトごとに新しいアカウントを作成する必要があり、各サイトは（例えば）サインアップ時に異なる必須フィールドを持つ可能性があります。私たちは大部分を埋めることができますが、それらを確認する必要があります。アバターは、Gravatar などで既に十分にサポートされています。
認証情報の記憶について：頻繁にログインしないコミュニティを使用する最良の方法は、メールログインです。可能であれば、私は常にそれを使用しています。
別のアイデンティティプロバイダーになることを検討する前に、解決する必要がある具体的な問題を見てみたいと思います。分散化はバグではなく、機能だと考えています 
「いいね！」 6
sam
(Sam Saffron)
7
この件についてですが、私が 100% 賛成するテーマコンポーネントの 1 つは、認証を 100% メールベースに変更するものです。
- 登録するには…メールアドレス、ユーザー名、名前を入力するだけです…パスワードは不要です。
- ログインするには…メールアドレスを入力するだけです…パスワードは不要です。
すでにメールによるパスワードレスログインをサポートしていますが、少し隠れてしまっています。パスワードを廃止すれば、これが完全に明確になり、多くの手間が省けるでしょう。
現時点では Discourse のデフォルトではありませんが、非常に興味深いテーマコンポーネントだと思います。
「いいね！」 1
