ユーザーが、他のユーザーにグループおよび関連するグループ資料へのアクセスを許可する際に手数料を課すことは可能でしょうか？標準機能ではないことは承知していますが、実現可能でしょうか？
有料グループメンバーシップ（特定のカテゴリへのアクセス権を付与する機能）は既存の機能です。#plugins チャンネルをご覧ください。
例としては、Patreon、Procourse Memberships、Subscriptia などがあります。
すでにメンバーシップを管理する既存のウェブサイトをお持ちの場合は、SSO ペイロードを通じてグループメンバーシップ情報を提供することも可能です。
ユーザーは自分が所有していないサイト上で直接他者から料金を徴収することはできませんが、そもそもそのような機能を付与することに意味があるでしょうか？
@Stephen 返信ありがとうございます。ご提示いただいた例や SSO オプションについては承知しています。
それは理にかなっているでしょうか？どんなことでも理にかなうかもしれません。活発なフォーラムを想像してみてください。素晴らしいコンテンツクリエイターが集まり、議論や問題解決に取り組んでいます。しかし、彼らは有料メンバーのみがアクセスできるプライベートグループも作成できるかもしれません。こうすれば、フォーラム参加者はフォーラム上での活動を収益化でき、フォーラムオーナーも収益を分割またはコミッションとして得ることができます。三方よしの仕組みです。
これが可能かどうかだけ気になっています。@angus、一般的に（引用は求めていませんが）、このようなことは可能に見えるでしょうか？
他人をタグ付けしないでください。
コードを一切書かずにユーザーとサービスプロバイダーを接続する方法には、考慮すべき多くの含意があります。例えば Marketplace では、特別なコードや決済処理を必要とせずにユーザーがコンサルタントと接続されます。
このような取引の管理は非常に厄介でリスクの高いプロセスです。EU や米国では、マネーロンダリング防止法も多数考慮する必要があります。
このアイデアを思いつく人は大勢いますが、結局のところ、どのクリエーターも月額5ドルで独自のDiscourseを立ち上げ、仲介手数料を回避できます。これは素晴らしいことであり、Discourseの核心的な使命の一つは、ウェブ上の分散化を促進することです。
@Falco さん、返信ありがとうございます。確かに、クリエイター各自が独自の Discourse を立ち上げることは可能です。しかし、複数のクリエイターが相互に議論できる一つの Discourse を設け、そこに有料の専門資料を提供することで、人々がまずクリエイターを見つけられるプラットフォームを構築できるはずです。そこに価値があるのです。この種の機能は実現不可能だと推察しております。フィードバックをありがとうございます！
その機能は完全に実現可能です。もちろん、開発費の調達が必要です。1万ドルあれば、ProCourse Memberships 💸 を改変して、複数の「メンバーシップ」を購入できるようにすれば対応できるでしょう。各メンバーシップは特定のグループへのアクセス権を付与し、各グループは特定のカテゴリへのアクセス権を付与します。
@Joshua_Kogan 現在、Custom Wizard プラグインを使用すれば、以下の 2 つの方法でこの処理を実行できます。
外部で支払いを受ける
1 つの方法は、カスタムウィザードの特定のステップが送信された際に、ユーザーを支払いプロバイダーへリダイレクトし、許可されたパラメータと必須データの組み合わせを使用して支払いが完了したことを確認した後、次のステップで「グループに追加」アクションを用いてユーザーをグループに追加するというものです。
以下は、このアプローチにおける支払い部分の詳細な説明です。「グループに追加」部分については自明と思われますので割愛します。
ユーザーを支払いプロバイダー設定へ誘導する
-
Route To アクション
「Route To」と呼ばれる新しいアクションタイプがあり、ステップの送信時にユーザーを特定の URL へ誘導できます。ウィザードでは、このアクションはユーザーの支払いが発生する前のステップに追加する必要があります。現在、デフォルトでは「payment」ステップ自体に追加されていますが、必要に応じてこのステップを削除し、直前のステップに追加することも可能です。
Route To アクションには現在、以下の 2 つの設定があります。-
url: 誘導先の URL です。他のウィザード入力と同様に、ウィザードフィールドには
w{}、ユーザーフィールドにはu{}を使用してデータを挿入できます。 -
code: 誘導先 URL にパラメータとして追加するための一意のコードです。この設定に値を入力すると、カスタムウィザードは一意のランダムな 16 進文字列を生成し、以下の処理を行います。
- 指定したキーを使用して、追加のクエリパラメータとして URL に追加する
- 指定したキーを使用して、送信データにこのコードを保存する
各リクエストに一意のキーを関連付けることで、そのリクエストに対する任意のコールバック（つまり、ユーザーがウィザードに戻ってきた場合）を検証できます。Chargify の場合、Chargify はパラメータ「reference」に送信した任意の値を保存します（詳細はこちら）。その後、Chargify が支払い完了後にユーザーをリダイレクトする「リターン URL」にこの値を追加します。
-
-
Permitted Params
これは新しいステップ設定で、そのステップに対して許可されるクエリパラメータと、それらを送信データに保存する際のキーを指定できます。これにより、ユーザーがウィザードにアクセスした経路などの統計的・分析的データを保存したり、コールバック処理に利用したりできます。Chargify の場合、ユーザーを支払い完了のために Chargify へリダイレクトする際に「reference」コードを Chargify に渡す（かつ送信データに保存）しました。その後、このコードを「リターン URL」に リターンパラメータ として追加し、リターンパラメータで指定したcustomer_referenceを保持するパラメータを保存することで、送信データに記録しました。
なお、Chargify では、「リターン URL」を「Route To」アクションを付与したステップの直後のステップの URL に設定する必要があります。つまり、その同じステップにcustomer_referenceパラメータを許可されたパラメータとして追加することになります。 -
Required Data
これは新しいステップ設定で、ユーザーがステップを表示する前にデータチェックを課すことができます。現在、送信データの一部が他の送信データの一部と等しいことを要求できます。
ユーザーがステップの読み込みを試み、必要なデータチェックに失敗すると、エラーメッセージが表示されます。Chargify の場合、この機能を使用して、「Route To」アクションで生成したコードが、Chargify から返されたcustomer_referenceと一致することを要求します。
ユーザーに表示されるエラーメッセージは、ウィザード管理画面の「データが存在しない場合に表示するメッセージ」フィールドでカスタマイズできます。また、エラーメッセージには「ウィザードを再開」リンクが付加されており、ユーザーはこれをクリックしてウィザードをステップ 1 にリセットし、既存の入力をクリアできます。
内部で支払いを受ける
ProCourse Memberships を使用して支払いを受けることも可能です。
また、OAuth2 または基本認証（Basic authorization）をサポートする API を備えたほぼすべての支払いプロバイダー（例：Stripe は基本認証を使用）を使用することもできます。その場合は、Custom Wizard の「Send to API」アクションと、関連する API エンドポイント管理システムを使用して API 接続を設定します。設定方法はプロバイダーによって異なります。このアプローチは安定性がやや劣りますが、ベータ機能であり、大きな可能性を秘めています。
これは直接的な解決策ではありませんが、近いです: Discourse Subscriptions Plugin
法的な問題を無視すれば、OPの要件をほとんど、あるいは全くコードなしで満たすことができる既存のオンラインサブスクリプションサービスがあります。例えば、Zapierのようなサービスは、サブスクリプションサービスとDiscourseフォーラムの中間役として機能することができます。サブスクリプションに基づいてDiscourseグループにユーザーを追加したり削除したりできます。
Discourse/WordPressの統合と少しのカスタム開発でも実現できると確信しています。
自分で調べてみたところ、技術的な課題よりも、有料サブスクリプションに基づいたグループメンバーシップの管理の方が法的な問題が障害となる可能性が高いようです。現在このようなことを行っている（Youtube、Paetron、Substack、X/Twitter）と認識している組織は、おそらく優秀な法務チームを抱えているでしょう。
グループ/カテゴリへのアクセスを収益化することに対する哲学的な異論については不明です。
これが話題から逸れているのか、それともまさに話題に沿っているのか分かりませんが、私の理解では、Stripe はマーチャント・オブ・レコード (MoR) として機能しません。MoR として機能する他のオンライン決済処理業者も存在します。その意味合いについては、他の皆さんに調査していただければと思います 
ここまで来ると私の頭は混乱し始め、グループアクセスを収益化する技術的な側面よりも、その法的な側面の方がはるかに daunting に思えてきます。
「マーチャント・オブ・レコード」として決済代行会社が機能することについて、具体的にどのような意味なのかよくわかりません。マーチャント識別番号（Merchant Identification Number）のことでしょうか？
Stripeでは確かにそれを持っておらず、数字と文字が混在した紛らわしい口座番号しかありません。他の決済代行会社であるElavonは、加盟店に10桁の加盟店ID番号を発行しており、これは彼らがマーチャント・オブ・レコードとして機能していることを意味するかもしれませんが、それが何を意味するのかはわかりません。
元のグループへのアクセスを収益化するというトピックについて、それが機能するかどうかは、グループが何について、あるいは何のためにあるのかに大きく依存します。ディスコースページがあれば、他のクリエイターが制作しているものに購読すること、そして誰かが他の人のフォーラムで自分の資料を公開する機会の両方を意味する可能性があります。
標準的なティアのホスティングは月額100ドルで、10人が月額10ドルを支払ってホストされたフォーラムのアカウントを持つことを望む場合、これはより手頃な価格になり、コストをカバーできます。
Google Workspaceのような他のサービスはユーザーあたり月額7ドルで、ビジネスメールは一般的に月額約13ドルです。Stripeや他の決済プラットフォームを使用して、利益を生み出さないが、グループコミュニケーションシステムを実行するためのコストをカバーするだけのユーザー料金を徴収することができます。
これは良いサイトポリシーに関する質問であり、多くのサイトではおそらく理にかなっていないでしょう。
多くの場合、セルフプロモーションや広告の投稿を禁止するポリシーがあるため、一般的に第三者による販売の試みは、ほとんどの管理者によって禁止されるでしょう。
Meta の Marketplace カテゴリは、グループへのアクセスにお金を要求したり、有料でサービスを提供しようとしたり、何かを販売しようとしたりするのではなく、有料の仕事のオファーを投稿するためだけのもののように見えますか？
また、マーケットプレイスのオファーは公開されていなければならず、クローズドメッセージングではいけないというポリシーもあります。これは良いポリシーのように思えます。
これは、
マーチャント・オブ・レコード（MoR）とは、エンドカスタマーに商品やサービスを販売する責任を負う法人のことです。売上税の徴収、Payment Card Industry（PCI）コンプライアンスの確保、返金やチャージバックの処理など、関連するすべての支払いと責任を負います。
グループオーナーがグループメンバーシップやDiscourseカテゴリへのアクセスに対して課金できるようにすることが理にかなっている理由についてですが、最も明白な答えは、「クリエイター」エコノミーが巨大であり、Discourseがその分野で機能する可能性があるということです。クリエイターエコノミーはコミュニティがすべてです。Discourseはコミュニティを構築するためのツールなので、その分野に適しています。
より推測的な答えとしては、通常のクリエイターエコノミーの範囲外の活動に資金を提供するための、クラウドファンディングやパトロンへの移行の傾向があると考えています。
Discourseベースのカテゴリレベルのサブスクリプションサービスは、無料のDiscourseホスティングを収益性をもって提供する最も簡単な方法かもしれません。フォーラムオーナーが利益の一部を受け取ると仮定します。Substackは、これがどのように機能するかを示す良いモデルです。
このトピックで以前に提起された、Discourseがウェブ上の分散化を促進することを目指しているという点は有効です。しかし、可能な中間点があります。Discourseはオープンソースソフトウェアであり、カテゴリのエクスポートとインポートを可能にするツールを備えています。特定のフォーラムのグループオーナーは、希望する場合、コミュニティをエクスポートする機能を与えることができます。物理的なビジネスのオーナーが店舗を新しい場所に移転するの（よりも簡単）に似ています。
PCIコンプライアンスは非常に複雑で難しいです。地元の銀行でマーチャントサービスアカウントを設定した際に、そのためのフォームをいくつか確認しました。彼らのカードリーダーはクローズド暗号化システムを使用しており、おそらくMoRとしての法的リスクを負っていることを意味しますが、これはStripeの場合は当てはまらないとあなたが正しく指摘していることだと思います。
独立したサーバーで支払いカード情報を処理している場合、セキュリティ要件に関する規制が何ページにもわたってあり、それらは非常に厳格で、違反した場合の罰金も高額です。
これは興味深いアイデアですが、それがどのように実現できるかはわかりません。
手動で、以前のバックアップから新しいフォーラムを開始し、エクスポートしたいカテゴリ以外のすべてを除外することはできますか？それでうまくいきますか、それとも他に方法がありますか？
Discourseには、カテゴリとグループのエクスポートおよびインポート用のrakeタスクがあります：https://meta.discourse.org/t/administrative-bulk-operations/118349#exportimport-categories-10。グループPMのエクスポートには使用できないと思いますが、グループメンバーや通常のカテゴリで行われたグループアクティビティのインポート/エクスポートは処理できます。
なるほど、その機能があることを知っておくと良いですね。