هل يمكن للمستخدمين فرض رسوم للسماح للمستخدمين الآخرين بالوصول إلى مجموعاتهم ومواد المجموعة ذات الصلة؟ أعرف أن هذه ليست ميزة جاهزة، ولكن هل هي ممكنة؟
عضوية المجموعة المدفوعة (التي تمنح بدورها الوصول إلى فئات محددة) هي ميزة موجودة. اطلع على #plugins
تشمل الأمثلة Patreon، وProcourse Memberships، وSubscriptia.
إذا كان لديك موقع ويب موجود يتعامل مع مثل هذه العضويات، فيمكنك أيضًا تسليم معلومات عضوية المجموعة عبر حمولة SSO الخاصة بك.
لا يمكن للمستخدمين تحصيل رسوم من الآخرين مباشرةً على موقع لا يملكونه، فهل من المنطقي أن يتمكنوا من ذلك حتى؟
شكرًا لك على الرد، @Stephen. أنا على علم بالأمثلة التي أدرجتها، وكذلك خيار SSO.
هل يبدو ذلك منطقيًا؟ أي شيء يمكن أن يبدو منطقيًا. تخيل منتدى حيويًا يجتمع فيه صناع محتوى رائعون للمناقشة وحل المشكلات؛ ومع ذلك، يمكنهم أيضًا إنشاء مجموعات خاصة لا يمكن الوصول إليها إلا للأعضاء المدفوعين. بهذه الطريقة، يمكن لمشاركات المنتدى تحقيق الدخل من نشاطهم على المنتدى، ويمكن لمالك المنتدى تحقيق الدخل من خلال تقاسم الأرباح/العمولة. فوز-فوز-فوز.
أنا مهتم فقط بمعرفة ما إذا كان هذا ممكنًا. @angus، بشكل عام (لا أبحث عن اقتباس هنا)، هل يبدو أن شيئًا مثل هذا ممكن؟
يرجى عدم الإشارة إلى الأشخاص.
هناك العديد من الآثار التي يجب أخذها في الاعتبار، بالإضافة إلى أمثلة على كيفية ربط المستخدمين بمقدمي الخدمات دون كتابة أي كود. خذ على سبيل المثال #marketplace، حيث يتم ربط المستخدمين بالاستشاريين دون الحاجة إلى كود خاص أو معالجة مدفوعات.
إدارة هذه الأنواع من المعاملات عملية شائكة ومحفوفة بالمخاطر للغاية. داخل الاتحاد الأوروبي والولايات المتحدة، يجب أيضًا مراعاة العديد من قوانين مكافحة غسيل الأموال.
كثير من الناس يأتون بهذه الفكرة، لكن في النهاية يمكن لأي صانع محتوى أن يمتلك منتدى خاصًا به على منصة Discourse مقابل 5 دولارات شهريًا ويتجاوز رسوم الوسيط. وهذا أمر رائع، حيث تُعد تعزيز اللامركزية على الويب واحدة من المهام الأساسية لمنصة Discourse.
شكرًا على الرد، @Falco. في الواقع، يمكن للمبدعين بدء منصات discourse الخاصة بهم؛ ومع ذلك، فإن وجود منصة discourse واحدة يجمع العديد من المبدعين للتحدث مع بعضهم البعض، ثم تقديم مواد متخصصة مقابل رسوم، سيُشكّل منصة تتيح للناس العثور على المبدع من البداية. هذا هو القيمة. أستنتج أن هذا النوع من الوظائف غير ممكن. شكرًا على ملاحظاتك!
الوظيفة ممكنة تمامًا. بالطبع، ستحتاج إلى تمويل تطويرها. أعتقد أنه بمبلغ 10 آلاف دولار يمكنك الحصول على نسخة معدلة من ProCourse Memberships 💸 لتمكين الأعضاء من شراء عضويات متعددة. تمنح كل عضوية الوصول إلى مجموعة، وتمنح كل مجموعة الوصول إلى فئة.
@Joshua_Kogan يمكنك القيام بذلك الآن بطريقتين مختلفتين باستخدام إضافة Custom Wizard.
استلام الدفع خارجيًا
تتمثل إحدى الطرق في توجيه المستخدم إلى مزود الدفع عند إكمال أحد خطوات السحرة المخصصة، والتأكد من إتمام الدفع باستخدام مزيج من المعلمات المسموح بها والبيانات المطلوبة، ثم إضافة المستخدم إلى مجموعة في الخطوة التالية (باستخدام إجراء “إضافة إلى المجموعة”).
هذا وصف كامل لجزء الدفع في هذا النهج. أما جزء إضافة المجموعة فمفهوم بحد ذاته:
إعداد توجيه المستخدم إلى مزود الدفع
- Route To Action: يوجد نوع إجراء جديد يُسمى “Route To” يسمح لك بتوجيه المستخدم إلى عنوان URL وجهة عند إكمال خطوة. بالنسبة إلى السحرة الخاصة بك، يجب إضافة الإجراء إلى أي خطوة تسبق عملية دفع المستخدم. حاليًا، تُضاف إلى خطوة “الدفع” نفسها، لكن يمكنك إزالة هذه الخطوة وإضافتها إلى الخطوة السابقة إذا رغبت. يحتوي إجراء “Route To” حاليًا على إعدادين:
-
url: هذا هو عنوان URL الوجهة. كما هو الحال مع مدخلات السحر الأخرى، يمكنك دمج البيانات باستخدام w{} لحقول السحر و u{} لحقول المستخدم.
-
code: رمز فريد يُضاف كمعلمة إلى عنوان URL الوجهة. عند ملء هذا الإعداد، تقوم السحرة المخصصة بتوليد سلسلة عشوائية فريدة من نوعها (hex) تقوم بـ:
- إضافتها إلى عنوان URL كمعلمة استعلام إضافية باستخدام المفتاح الذي توفره؛ و
- حفظ الرمز في بيانات الإرسال باستخدام المفتاح الذي توفره
يسمح ربط مفتاح فريد بكل طلب بالتحقق من أي استدعاء عائد لهذا الطلب (أي عندما يعود المستخدم إلى السحر). في حالة Chargify، سيقوم Chargify بتخزين أي قيمة ترسلها في المعلمة ‘reference’ (انظر المزيد)، والتي يمكنك إضافتها إلى ‘عنوان URL للإرجاع’ الذي يعيد Chargify توجيه المستخدم إليه بعد إتمام الدفع.
-
Permitted Params: هذا إعداد جديد للخطوة يسمح لك بتحديد معلمات الاستعلام المسموح بها للخطوة والمفتاح الذي يجب حفظها به في بيانات الإرسال. يمكنك استخدامه لحفظ بيانات إحصائية أو تحليلية (مثل مكان دخول المستخدم إلى السحر)، وللاستدعاءات العائدة. في حالة Chargify، قمنا بتمرير رمز ‘reference’ إلى Chargify (وقمنا بحفظه في بيانات الإرسال) عند توجيه المستخدم إلى Chargify لإكمال الدفع. ثم قمنا بإضافة هذا الرمز إلى ‘عنوان URL للإرجاع’ كمعلمة إرجاع return parameter، ثم قمنا بحفظها في الإرساليات بإضافة أي معلمة نحددها لحمل
customer_referenceفي معلمات الإرجاع. لاحظ أنه في Chargify ستحتاج إلى تعيين ‘عنوان URL للإرجاع’ إلى عنوان URL للخطوة التالية للخطوة التي أرفقت بها إجراء ‘Route To’. هذا يعني أنك ستضيف معلمةcustomer_referenceكمعلمة مسموح بها لتلك الخطوة نفسها. -
Required Data: هذا إعداد جديد للخطوة يسمح لك بفرض فحص بيانات قبل السماح للمستخدم بعرض الخطوة. حاليًا، يمكنك اشتراط أن تساوي قطعة من بيانات الإرسال قطعة أخرى من بيانات الإرسال. إذا حاول المستخدم تحميل الخطوة وفشل فحص البيانات المطلوب، فسيرى رسالة خطأ. في حالة Chargify، سنستخدم هذا لاشتراط أن يساوي الرمز الذي أنشأناه في إجراء “Route To” قيمة
customer_referenceالتي يعيدها Chargify. يمكنك تخصيص رسالة الخطأ المعروضة للمستخدمين باستخدام حقل “الرسالة المعروضة عند عدم وجود البيانات” في إدارة السحر. بالإضافة إلى ذلك، يوجد رابط “إعادة تشغيل السحر” مضاف إلى رسالة الخطأ يسمح للمستخدم بإعادة تعيين السحر إلى الخطوة 1 ومسح المدخلات الحالية.
استلام الدفع داخليًا
يمكنك استخدام ProCourse Memberships لاستلام الدفع.
كما يمكنك استخدام أي مزود دفع تقريبًا إذا كان يدعم واجهة برمجة التطبيقات (API) التي تدعم OAuth2 أو المصادقة الأساسية (على سبيل المثال، يستخدم Stripe المصادقة الأساسية)، من خلال إعداد اتصال API باستخدام إجراء “Send to API” في Custom Wizard ونظام إدارة نقطة نهاية API المرتبط به. سيعتمد كيفية إعداد ذلك على المزود. هذا النهج أقل استقرارًا؛ إنه ميزة في مرحلة الاختبار (beta)، لكنه يحمل إمكانات كبيرة.
هذا لا يحل المشكلة بشكل مباشر، ولكنه قريب: Discourse Subscriptions Plugin
مع تجاهل المشكلات القانونية المحتملة، هناك خدمات اشتراك عبر الإنترنت موجودة يمكن استخدامها على الأرجح لتلبية متطلبات OP (صاحب الموضوع) مع القليل من التعليمات البرمجية أو بدونها. على سبيل المثال، يمكن لخدمة مثل Zapier أن تعمل كوسيط بين خدمة اشتراك ومنتدى Discourse. يمكنها إضافة وإزالة المستخدمين من مجموعات Discourse بناءً على اشتراكاتهم.
أنا متأكد من أنه يمكن تحقيق ذلك أيضًا من خلال التكامل بين Discourse و WordPress وبعض التطوير المخصص.
من خلال البحث في هذا الأمر بنفسي، يبدو أن المشكلات القانونية المحتملة قد تكون عقبة أكبر من التحديات التقنية لإدارة عضويات المجموعات بناءً على الاشتراكات المدفوعة. المنظمات التي أعرفها والتي تقوم بهذا النوع من الأشياء الآن (Youtube، Paetron، Substack، X/Twitter) لديها على الأرجح فرق قانونية جيدة.
أنا غير متأكد من الاعتراضات الفلسفية على تحقيق الدخل من الوصول إلى المجموعات/الفئات.
لست متأكدًا مما إذا كان هذا يخرج عن الموضوع، أو بالضبط في صلب الموضوع، ولكن فهمي هو أن Stripe لا تعمل كـ “Merchant of Record” (MoR). هناك معالجات دفع أخرى عبر الإنترنت تعمل كـ “Merchant of Record”. سأترك للآخرين البحث في تداعيات ذلك. هذه هي النقطة التي يبدأ فيها رأسي بالدوران وأبدأ في التفكير في أن الجوانب التقنية لتحقيق الدخل من الوصول الجماعي أقل صعوبة بكثير من الجوانب القانونية لذلك 
لست على دراية بما يعنيه بالضبط أن يعمل معالج الدفع كـ “تاجر مسجل”، هل تتحدث عن رقم تعريف التاجر؟
صحيح أنني لا أملك ذلك مع Stripe، فقط رقم حساب مربك يتكون من مزيج من الأرقام والأحرف. معالج الدفع الآخر Elavon يمنح التجار رقم معرف التاجر المكون من 10 أرقام، مما قد يعني أنهم يعملون كتاجر مسجل ولكنني لا أعرف ماذا يعني ذلك.
فيما يتعلق بالموضوع الأصلي لتحقيق الدخل من الوصول إلى مجموعة، فإن نجاح ذلك يعتمد حقًا على ماهية المجموعة أو الغرض منها، مع صفحة مناقشة يمكن أن تعني الاشتراك في ما ينتجه منشئ آخر بالإضافة إلى فرصة للأشخاص لنشر موادهم الخاصة في منتدى شخص آخر.
مع تكلفة استضافة المستوى القياسي 100 دولار شهريًا، يصبح هذا ميسور التكلفة إذا أراد عشرة أشخاص دفع 10 دولارات شهريًا للحصول على حسابات في منتدى مستضاف يغطي التكلفة.
تكلف خدمات أخرى مثل Google Workspace 7 دولارات شهريًا لكل مستخدم، وعادة ما يكون البريد الإلكتروني التجاري حوالي 13 دولارًا شهريًا، ويمكن استخدام Stripe أو منصة دفع أخرى لجمع رسوم المستخدمين لتلك الخدمة التي لا تحقق أي ربح ولكنها تغطي فقط تكلفة تشغيل نظام اتصالات المجموعة.
هذا سؤال جيد حول سياسة الموقع، وبالنسبة للعديد من المواقع، ربما لا يكون ذلك منطقيًا.
غالبًا ما تكون هناك سياسات بعدم الترويج الذاتي أو نشر الإعلانات، لذا بشكل عام، فإن أي محاولة للبيع من قبل أطراف ثالثة ستكون على الأرجح محظورة من قبل معظم المسؤولين.
مع فئة Marketplace لـ Meta، يبدو أنها مخصصة فقط لنشر عروض العمل المدفوع، وليس لأي شخص يطلب المال للوصول إلى مجموعة أو يحاول تقديم خدمة مقابل أجر أو بيع أي شيء؟
هناك أيضًا سياسة مفادها أن أي عرض في السوق يجب أن يكون عامًا وليس في رسائل مغلقة، ويبدو أن هذه سياسة جيدة.
هذا:
التاجر المسجل (MoR) هو كيان قانوني مسؤول عن بيع السلع أو الخدمات للعميل النهائي. يتولون جميع المدفوعات ويتحملون المسؤوليات المرتبطة بها، مثل تحصيل ضريبة المبيعات، وضمان الامتثال لمعايير صناعة بطاقات الدفع (PCI)، وتكريم عمليات استرداد الأموال والنزاعات.
فيما يتعلق بـ سبب منطقية السماح لمالكي المجموعات بتحصيل رسوم مقابل عضويات المجموعات والوصول إلى فئات Discourse، فإن الإجابة الأكثر وضوحًا هي أن اقتصاد “المبدعين” ضخم ولديه القدرة على العمل في هذا المجال. يتعلق اقتصاد المبدعين بالمجتمع. Discourse هي أداة لبناء المجتمعات، لذا ستكون مناسبة لهذا المجال.
إجابة أكثر تخمينًا هي أنني أعتقد أن هناك اتجاهًا نحو التمويل الجماعي والرعاية لتمويل الأنشطة التي تقع خارج اقتصاد المبدعين العادي.
قد تكون خدمة اشتراك على مستوى الفئة تستند إلى Discourse أيضًا أسهل طريقة لتوفير استضافة Discourse مجانية بشكل مربح. أفترض أن مالك المنتدى سيحصل على حصة من الأرباح. Substack هو نموذج جيد لكيفية عمل ذلك.
النقطة التي أثيرت سابقًا في هذا الموضوع بأن Discourse تهدف إلى تعزيز اللامركزية على الويب صحيحة. ولكن هناك أرضية وسط محتملة. Discourse هو برنامج مفتوح المصدر ولديه أدوات تسمح بتصدير واستيراد الفئات. يمكن منح مالك المجموعة في منتدى معين القدرة على تصدير مجتمعه إذا رغب في ذلك. يشبه ذلك (ولكنه أسهل من) الطريقة التي يمكن لمالك عمل تجاري فعلي نقل متجره إلى موقع جديد.
الامتثال لمعايير PCI مربك وصعب للغاية، لقد مررت ببعض النماذج الخاصة بذلك عندما قمت بإعداد حساب خدمة التاجر مع البنك المحلي. تستخدم أجهزة قراءة البطاقات الخاصة بهم نظامًا مشفرًا مغلقًا مما يعني على الأرجح أنهم يتحملون المخاطر القانونية لكونهم مزود خدمة معتمد (MoR)، وهو ما أعتقد أنك على حق في قوله ليس هو الحال بالنسبة لـ Stripe.
إذا كان أي شخص يعالج معلومات بطاقات الدفع على خوادم مستقلة، فهناك صفحات وصفحات من اللوائح التي يجب المرور بها مع جميع المتطلبات الأمنية، وهي متطلبات ثقيلة وهناك غرامات باهظة في حالة الفشل.
هذه فكرة مثيرة للاهتمام، لست متأكدًا من كيفية القيام بذلك.
يدويًا، يمكن بدء منتدى جديد من نسخة احتياطية سابقة، باستثناء كل شيء ما عدا الفئة التي يريد شخص ما تصديرها. هل سينجح ذلك، أم ستكون هناك طريقة أخرى؟
لدى Discourse مهام rake لاستيراد وتصدير الفئات والمجموعات: https://meta.discourse.org/t/administrative-bulk-operations/118349#exportimport-categories-10. لا أعتقد أنه يمكن استخدام هذا لتصدير رسائل المجموعة الخاصة، ولكنه سيتعامل مع استيراد/تصدير أعضاء المجموعة والنشاط الجماعي الذي حدث في الفئات العادية.
حسناً، من الجيد معرفة أن لديها هذه الإمكانية.