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。我将把研究其影响的任务留给其他人。这就是我的头脑开始打转的地方，我开始认为，将群组访问货币化的技术方面比其法律方面要容易得多 
2 个赞
我不太清楚支付处理商充当“记账商户”具体意味着什么，您是在说商户识别号吗？
确实，我在 Stripe 上没有这个号码，只有一个由数字和字母混合组成的令人困惑的账号。另一家支付处理商 Elavon 为商户提供一个 10 位数的商户 ID#，这可能意味着他们确实充当记账商户，但我不知道那是什么意思。
关于将访问权限货币化的原始话题，这是否可行很大程度上取决于该群组是关于什么或为了什么。对于一个论坛页面，这可能意味着订阅另一个创作者正在制作的内容，也可能意味着人们有机会在别人的论坛上发布自己的材料。
标准套餐托管每月费用为 100 美元，如果十个人想每月支付 10 美元来获得托管论坛的账户，以覆盖成本，那么这会更实惠。
其他服务，如 Google Workspace 每月每用户 7 美元，商务电子邮件通常每月约 13 美元，可以使用 Stripe 或其他支付平台来收取用户费用，这些费用不产生任何利润，只是用于支付运行群组通信系统的成本。
这是一个很好的网站政策问题，对于许多网站来说，这可能没有意义。
通常有禁止自我推销或发布广告的政策，因此大多数管理员通常会禁止任何第三方销售尝试。
Meta 的 Marketplace 类别似乎只用于发布付费工作机会，而不是任何人要求付费加入群组或尝试提供付费服务或销售任何东西？
还有任何市场报价都必须公开而不是在私信中进行的政策，这似乎是一项好政策。
这是：
记录商家（MoR）是负责向最终客户销售商品或服务的法律实体。他们处理所有付款并承担相关责任，例如征收销售税、确保符合支付卡行业（PCI）标准以及处理退款和拒付。
就为什么允许群组所有者收取群组会员费和访问 Discourse 分类而言，最明显的答案是“创作者经济”非常庞大，而 Discourse 有潜力在该领域运营。创作者经济的核心是社区。Discourse 是一个用于构建社区的工具，因此非常适合该领域。
更具推测性的答案是，我认为有一种趋势是众筹和赞助，用于资助那些不属于正常创作者经济范围的活动。
基于 Discourse 的分类级别订阅服务也可能是盈利性地提供免费 Discourse 托管的最简单方法。我假设论坛所有者会从中获利。Substack 是一个很好的模型，展示了这可以如何运作。
本主题早些时候提出的关于 Discourse 旨在促进网络去中心化的观点是有效的。但可能存在一个折衷方案。Discourse 是开源软件，并提供了导出和导入分类的工具。特定论坛上的群组所有者可以被授予导出其社区的能力（如果他们愿意）。这类似于（但比）实体企业所有者将其商店搬到新址的方式。
1 个赞
PCI 合规性非常令人困惑且困难。在我与当地银行设置商户服务账户时，我填写了一些相关的表格。他们的读卡器使用封闭的加密系统，这可能意味着他们承担了作为 MoR（商户）的法律风险，我相信您说 Stripe 不是 MoR 是正确的。
如果有人在独立服务器上处理支付卡信息，那么有许多规定需要遵守，其中包含所有安全要求，这些要求非常严格，并且在未能遵守的情况下会有高额罚款。
这是一个有趣的想法，但不确定该如何实现。
手动创建一个新的论坛，可以从之前的备份中进行，排除除某个用户想要导出的类别之外的所有内容。这样可以吗，还是有其他方法？
1 个赞
Discourse 有用于导入和导出类别和群组的 rake 任务：https://meta.discourse.org/t/administrative-bulk-operations/118349#exportimport-categories-10。我不认为这可以用于导出群组私信，但它可以处理在常规类别中发生的群组成员和群组活动的导入/导出。
好的，很高兴知道它有这个功能。