ユーザーが サブフォーラム を作成できるようにする方法を模索しています。これは Slack チャンネルのように動作するものです。
そのための提案の一つに、タグを使用するというものがありました。ユーザーがタグを作成するか、私が開発したアプリが API を通じて作成し、そのタグのページをサブフォーラムのページのように機能させるというものです。
問題は、そのサブフォーラムのメンバーのみが投稿できるようにする方法です。つまり、そのサブフォーラムのメンバーのみが、投稿にそのサブフォーラムのタグを関連付けられるようにする必要があるということです。
これを「ユーザーのカスタムフィールド」を使って実現できるでしょうか？特定のタグで投稿することを許可されたユーザーをマークする方法があればと考えています。
ユーザーのカスタムフィールドの用途についてはまだよく理解できていませんので、詳しく教えていただければ幸いです。
タグにはユーザーレベルの権限が伴わないと思います。カテゴリを確認されることをお勧めします。
Discourse では、コンテンツへのアクセス制御にグループとカテゴリを使用します。詳細については、このトピック内のビデオをご覧ください。プライベートカテゴリを作成するためのカテゴリのセキュリティ設定の使い方
ご回答ありがとうございます。カテゴリの方が簡単な方法であることに同意します。ただし、これらはユーザーが多数作成するサブフォーラムとなります。数百以上になる可能性があります（サブフォーラムはアプリの重要な要素であり、ユーザーベースの拡大に伴って成長します）。
数百〜数千のカテゴリを作成すると大きな問題になると言われているため、他の解決策を検討すべきだと伝えられました。他に提案はありますか？API と連携する別アプリを構築する用意はあります。Discourse から求める重要な機能は、優れた投稿・返信・タグ機能です。
あなたが作ろうとしているものは、Discourse が目指しているものではありません。
あなたが求めているのは、Reddit や Discord のようなプラットフォームで、ユーザーが自分たちの「所有する」サブレディットやサーバーを作成できるが、プラットフォーム全体の管理と収益化はあなたが維持する仕組みです。
Discourse はこれとは正反対を目的としており、各サブレディットやサーバー、ギルドが独自のサイトとして機能し、データを所有し、独自の URL で運用されることを想定しています。
オープンソースプロジェクトを大幅に改造することも可能ですが、あなたの要望に近い別のソリューションを利用することをお勧めします。
これは通常のユースケースではないことは理解していますが、Discourse が素晴らしいプラットフォームである以上、Discourse でこの機能を導入する方法を見つけたいと考えています。現在、API を使ってタグを作成し、そのタグページ（サブフォーラムのような役割を果たすページ）へユーザーを誘導することで、ある程度近い状態を実現できています。しかし、欠けている重要な点は、そのタグを使って投稿できるユーザーを制限する機能です。
Discord は、アプリとの統合に関する制限があるため、今回の目的には適していません。Reddit とアプリを統合する方法については、詳しくありません。
Reddit で実際にこれを実現できるというご提案でしょうか、それとも私が求めている機能の「種類」を指しただけでしょうか？
いずれにせよ、Discourse の最大の利点は、チャットではなくフォーラムである点だと考えています。ここで必要なのは、フォーラムのような機能です。Discourse に代わる選択肢を見たことはありませんが、もしあればぜひご提案いただければ幸いです。
その重要な点はロードマップに含まれておらず、追加する予定もありません。
過去数年間でこれに関する多数のトピックがありました：
それらは見ています。ここでの違いは、私は完全に別のアプリを構築し、Discourse API と連携させて、ユーザーがサブグループを作成しているような体験を提供することに前向きだということです。そのため、その別アプリ内でサブグループ自体を作成し、メンバーを関連付けるなどの処理を自分で行うことができます。
しかし、私が作成したそのサブフォーラムページにおいて、Discourse のフロントエンドの投稿機能（トピックの作成、返信、カテゴリへのリンク、タグの追加など）を引き続き利用したいと考えています。
ユーザーのカスタムフィールドとタグをリンクさせる（あるいはそれに近い仕組み）ことで、ユーザーが投稿できるタグを制限する方法があると教えられました。
しかし、根本的な希望は私が前述した通りです。サブフォーラムの設定の多くは私のアプリ側で処理できますが、Discourse の投稿機能をそのまま活用できれば、多くの時間を節約できるはずです。
ご返信いただきありがとうございます。ユーザーのカスタムフィールドが通常どのように使用されているか、具体例をいくつか教えていただけますでしょうか。
私の考えでは、許可された各ユーザーに特定のサブフォーラム（例：‘subforum123’）に関連するカスタムフィールドを追加し、ユーザーがサブフォーラムページにアクセスした際にAPIを呼び出して、そのユーザーに必要なカスタムフィールドを持っているかを確認するという方法が考えられます。もし持っていれば投稿が可能となり、持っていなければ投稿できず、その場合は「新規トピック作成」ボタンや「返信」ボタンを非表示にするといった対応が可能かもしれません。
これらは一般的に、サインアップ時に（所在地や役職などの）情報を収集し、プロフィールカードに表示するために使用されます。
おそらく、マルチサイトインストール上で動作する独自の Discourse（例：username.yoursite.com）を作成できるようにする必要があるでしょう。その際、あなたの「ホーム」Discourse をユーザー用サブサイトの SSO サーバーとして機能させます。新しいユーザーが作成されるたびに、新しい username.yoursite.com Discourse サイトを自動的に作成するプラグインを作成することも理論上は可能です。ただし、すべてのユーザーが独自のサブフォーラムを必要とするわけではないため、代わりに彼らがサブサイトを作成できるようにする何らかの仕組みが必要になるかもしれません。
これが、あなたが目指していることに近づいていると思います。
確かに、私が考えていたことに近づいていますね（「サブフォーラム」が目標でした）。ありがとうございます。マルチサイトについてさらに詳しく調べてみます。
マルチサイト構造でユーザーが独自のサブサイトを作成できるようにすることは、ユーザーが独自のカテゴリを作成できるようにするよりも、はるかにリソースを消費すると思っていたのですが。数百以上のサブサイトでもマルチサイトは機能するのでしょうか？サーバーへの負荷がどれほど大きくなるのか気になります。あるいは、繁忙な単一サイトと比べてそれほど負荷が増えないのでしょうか？
その通りです。ただし、実現可能であるという利点があります。
はい、少なくとも1社で、月額100〜300ドルで少なくとも2種類のプラグインセットを使用しながら、数百以上ものサブサイトを運用している企業を知っています。他社ではサイトあたり月額20ドルで課金しているところもあります。
もし不明な点があれば、基本的にはDiscourseのホスティング会社を構築することになります。
例えば、数十のサイトを運用する場合、開始時に4〜16GBのRAMが必要になります。
確認ですが、その企業が数百のサブサイトの維持に月額100〜300ドルを支払っているという意味でしょうか？（そうおっしゃっているようですが、数百のサブサイトに対しては相当低い金額ですね）
つまり、Discourse を開発しているあの会社は、作成しようとしているサイトあたり 100〜300 ドルを請求しています。他のいくつかのサービスは 月額 20 ドル程度 で、彼らももちろん利益を上げているはずです。
私が提案した問題を解決するには、おそらく少なくとも 100 時間以上かかります。もしかしたらそれ以上かもしれません。
追記：ただし、単一のマルチサイトが必要なだけなら、それよりも短い時間で開始できるかもしれません。
わかりました。ありがとうございます。