Is it possible for users to charge a fee to permit other users access to their groups, and related group materials? I know it is not an off-the-shelf feature, but is it possible?
Paid group membership (in turn granting access to specific categories) is an existing feature. Take a look in #plugins
Examples include Patreon, Procourse Memberships and Subscriptia.
If you have an existing website which handles such memberships you can also deliver group membership information via your SSO payload.
Users can’t charge others fees directly on a site they don’t own, would it make sense for them to even be able to?
「いいね！」 6
Thanks for the reply, @Stephen. I am aware of the examples that you’ve included, as well as the sso option.
Would it make sense? Anything can make sense. Imagine a lively forum with great content creators coming together for discourse and solving problems; however, they could also create private groups that only paying members could access. This way, the forum participants could monetize their activity on the forum, and the forum owner could monetize with a split/commission. Win-win-win.
I’m only curious if this is possible. @angus, generally speaking (not looking for a quote here), does something like this seem possible?
Please don’t tag people.
There are lots of implications here to be considered, and examples of how users can be connected to service providers without writing any code. Take the marketplace for example, users are connected to consultants without the need for special code or payment processing.
Managing these kinds of transactions is a very tricky and risky process. Within the EU and US you also have to consider the many money laundering laws.
A lot of people come up with this idea, but in the end any creator can have their own Discourse for $5 a month and skip the middleman fee. Which is a great thing, one of the core missions of Discourse is to promote decentralization on the web.
「いいね！」 4
Thanks for the reply, @Falco. Indeed creators can start-up their own discourse; however, having one discourse with many creators discussing with one another, then offering specialized materials for fee, would create a platform that lets people find the creator in the first place. That would be the value. I’m gathering that this type of functionality is not possible. Thanks for the feedback!
The functionality is completely possible. Obviously, you will need to fund the development of it. I think with $10K you can get a modified ProCourse Memberships 💸 to have multiple “memberships” members can buy would do it. Each membership gives access to a group, each group access to a category.
「いいね！」 4
@Joshua_Kogan You could do this right now in two different ways using the Custom Wizard plugin.
Take payment externally
One method would be to send the user to a payment provider upon submission of one step of a custom wizard, ensure the payment is completed using a combination of permitted params and required data, then add the user to a group on a subsequent step (using the “Add to Group” action).
This is a full description of the payment piece of this approach. The add to group piece should be self explanatory:
Send user to payment provider setup
- Route To Action . There’s a new action type called “Route To” that allows you to send a user to a destination url upon submission of a step. For your wizards, the action should be added to whatever step precedes the user’s payment. Currently they’re added to the ‘payment’ step itself, but you can remove this step and add them to the preceding step if you like.The route to action currently has two settings:
-
url: This is the destination url. As with other wizard inputs, you can interpolate data using w{} for wizard fields and u{} for user fields.
-
code: A unique code to add as a parameter to the destination url. When this setting is filled the custom wizard will generate a unique random hex string that it:
- adds to the url as an addtional query param using the key you provide; and
- saves the code in the submission data using the key you provide
Associating a unique key with each request allows any callback for that request (i.e. when the user returns to the wizard) to be validated. In the chargify case, chargify will store any value you send in the parameter ‘reference’ (see further), which you can then add to the ‘return url’ what chargify redirects the user to after they’ve completed payment.
-
Permitted Params . This a new step setting that allows you to specify what query params are permitted for the step and the key they should be saved with in the submission data. You can use this to both save statistical or analytical data (such as where the user has entered the wizard from), and for callbacks. In the chargify case we passed the ‘reference’ code to chargify (and saved it in the submission data) when we redirected the user to chargify to complete payment. We would then add this code to the ‘return url’ as a return parameter which we then save to the submissions by adding whatever paramter we specify as holding the
customer_referencein the return paramters.Note that in chargify you’ll need to set the ‘return url’ to url of the step after the step you attached the ‘route to’ action to. This means that you’ll be adding thecustomer_referenceparam as a permitted paramter to that same step. -
Required Data . This is a new step setting that allows you to impose a data check before allowing a user to view the step. Currently you can require a piece of submission data to equal another piece of submission data.If the user tries to load the step and the required data check fails, they’ll see an error message. In the chargify case we’ll use this to require the code we created in the “Route To” action to equal the customer_reference returned by chargify.You can customise the error message show to users using the “Message show when data not present” field in the wizard admin. Additionally, there is a “Restart Wizard” link appended to the error message allowing the user to reset the wizard to step 1 and clear existing inputs.
Take payment internally
You can use ProCourse Memberships to take payment.
You can also use almost any payment provider if they have an API that supports OAuth2, or Basic authorization (Stripe uses Basic authorization for exmple), by setting up an API connection using the Custom Wizard’s “Send to API” action and associated API endpoint management system. How you set this up will depend on the provider. This approach is less stable; it’s a feature in beta, but it has significant potential.
「いいね！」 6
これは直接的な解決策ではありませんが、近いです: Discourse Subscriptions Plugin
法的な問題を無視すれば、OPの要件をほとんど、あるいは全くコードなしで満たすことができる既存のオンラインサブスクリプションサービスがあります。例えば、Zapierのようなサービスは、サブスクリプションサービスとDiscourseフォーラムの中間役として機能することができます。サブスクリプションに基づいてDiscourseグループにユーザーを追加したり削除したりできます。
Discourse/WordPressの統合と少しのカスタム開発でも実現できると確信しています。
自分で調べてみたところ、技術的な課題よりも、有料サブスクリプションに基づいたグループメンバーシップの管理の方が法的な問題が障害となる可能性が高いようです。現在このようなことを行っている（Youtube、Paetron、Substack、X/Twitter）と認識している組織は、おそらく優秀な法務チームを抱えているでしょう。
グループ/カテゴリへのアクセスを収益化することに対する哲学的な異論については不明です。
「いいね！」 3
Stripe はそのようなものとしては私が知る限り最高のプラットフォームであり、さまざまな国で税金のために手数料をどのように分類できるかについて、多くの異なるオプションがあります。
これは、クリエイターが継続的にニュースレター、アートワーク、またはビデオプレゼンテーションを公開している場合に機能する可能性があります。著作権オプションには、制限付きまたは条件付きの権利のいずれかを選択できるさまざまなオプションがあります。
これが話題から逸れているのか、それともまさに話題に沿っているのか分かりませんが、私の理解では、Stripe はマーチャント・オブ・レコード (MoR) として機能しません。MoR として機能する他のオンライン決済処理業者も存在します。その意味合いについては、他の皆さんに調査していただければと思います 
ここまで来ると私の頭は混乱し始め、グループアクセスを収益化する技術的な側面よりも、その法的な側面の方がはるかに daunting に思えてきます。
「いいね！」 2
「マーチャント・オブ・レコード」として決済代行会社が機能することについて、具体的にどのような意味なのかよくわかりません。マーチャント識別番号（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はオープンソースソフトウェアであり、カテゴリのエクスポートとインポートを可能にするツールを備えています。特定のフォーラムのグループオーナーは、希望する場合、コミュニティをエクスポートする機能を与えることができます。物理的なビジネスのオーナーが店舗を新しい場所に移転するの（よりも簡単）に似ています。
「いいね！」 1
PCIコンプライアンスは非常に複雑で難しいです。地元の銀行でマーチャントサービスアカウントを設定した際に、そのためのフォームをいくつか確認しました。彼らのカードリーダーはクローズド暗号化システムを使用しており、おそらくMoRとしての法的リスクを負っていることを意味しますが、これはStripeの場合は当てはまらないとあなたが正しく指摘していることだと思います。
独立したサーバーで支払いカード情報を処理している場合、セキュリティ要件に関する規制が何ページにもわたってあり、それらは非常に厳格で、違反した場合の罰金も高額です。
これは興味深いアイデアですが、それがどのように実現できるかはわかりません。
手動で、以前のバックアップから新しいフォーラムを開始し、エクスポートしたいカテゴリ以外のすべてを除外することはできますか？それでうまくいきますか、それとも他に方法がありますか？
「いいね！」 1
Discourseには、カテゴリとグループのエクスポートおよびインポート用のrakeタスクがあります：https://meta.discourse.org/t/administrative-bulk-operations/118349#exportimport-categories-10。グループPMのエクスポートには使用できないと思いますが、グループメンバーや通常のカテゴリで行われたグループアクティビティのインポート/エクスポートは処理できます。
なるほど、その機能があることを知っておくと良いですね。