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 لا تعمل كـ “Merchant of Record” (MoR). هناك معالجات دفع أخرى عبر الإنترنت تعمل كـ “Merchant of Record”. سأترك للآخرين البحث في تداعيات ذلك. هذه هي النقطة التي يبدأ فيها رأسي بالدوران وأبدأ في التفكير في أن الجوانب التقنية لتحقيق الدخل من الوصول الجماعي أقل صعوبة بكثير من الجوانب القانونية لذلك 
إعجابَين (2)
لست على دراية بما يعنيه بالضبط أن يعمل معالج الدفع كـ “تاجر مسجل”، هل تتحدث عن رقم تعريف التاجر؟
صحيح أنني لا أملك ذلك مع Stripe، فقط رقم حساب مربك يتكون من مزيج من الأرقام والأحرف. معالج الدفع الآخر Elavon يمنح التجار رقم معرف التاجر المكون من 10 أرقام، مما قد يعني أنهم يعملون كتاجر مسجل ولكنني لا أعرف ماذا يعني ذلك.
فيما يتعلق بالموضوع الأصلي لتحقيق الدخل من الوصول إلى مجموعة، فإن نجاح ذلك يعتمد حقًا على ماهية المجموعة أو الغرض منها، مع صفحة مناقشة يمكن أن تعني الاشتراك في ما ينتجه منشئ آخر بالإضافة إلى فرصة للأشخاص لنشر موادهم الخاصة في منتدى شخص آخر.
مع تكلفة استضافة المستوى القياسي 100 دولار شهريًا، يصبح هذا ميسور التكلفة إذا أراد عشرة أشخاص دفع 10 دولارات شهريًا للحصول على حسابات في منتدى مستضاف يغطي التكلفة.
تكلف خدمات أخرى مثل Google Workspace 7 دولارات شهريًا لكل مستخدم، وعادة ما يكون البريد الإلكتروني التجاري حوالي 13 دولارًا شهريًا، ويمكن استخدام Stripe أو منصة دفع أخرى لجمع رسوم المستخدمين لتلك الخدمة التي لا تحقق أي ربح ولكنها تغطي فقط تكلفة تشغيل نظام اتصالات المجموعة.
هذا سؤال جيد حول سياسة الموقع، وبالنسبة للعديد من المواقع، ربما لا يكون ذلك منطقيًا.
غالبًا ما تكون هناك سياسات بعدم الترويج الذاتي أو نشر الإعلانات، لذا بشكل عام، فإن أي محاولة للبيع من قبل أطراف ثالثة ستكون على الأرجح محظورة من قبل معظم المسؤولين.
مع فئة Marketplace لـ Meta، يبدو أنها مخصصة فقط لنشر عروض العمل المدفوع، وليس لأي شخص يطلب المال للوصول إلى مجموعة أو يحاول تقديم خدمة مقابل أجر أو بيع أي شيء؟
هناك أيضًا سياسة مفادها أن أي عرض في السوق يجب أن يكون عامًا وليس في رسائل مغلقة، ويبدو أن هذه سياسة جيدة.
هذا:
التاجر المسجل (MoR) هو كيان قانوني مسؤول عن بيع السلع أو الخدمات للعميل النهائي. يتولون جميع المدفوعات ويتحملون المسؤوليات المرتبطة بها، مثل تحصيل ضريبة المبيعات، وضمان الامتثال لمعايير صناعة بطاقات الدفع (PCI)، وتكريم عمليات استرداد الأموال والنزاعات.
فيما يتعلق بـ سبب منطقية السماح لمالكي المجموعات بتحصيل رسوم مقابل عضويات المجموعات والوصول إلى فئات 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. لا أعتقد أنه يمكن استخدام هذا لتصدير رسائل المجموعة الخاصة، ولكنه سيتعامل مع استيراد/تصدير أعضاء المجموعة والنشاط الجماعي الذي حدث في الفئات العادية.
حسناً، من الجيد معرفة أن لديها هذه الإمكانية.