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 „Gefällt mir“
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 „Gefällt mir“
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 „Gefällt mir“
@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 „Gefällt mir“
Dies löst das Problem nicht direkt, ist aber nah dran: Discourse Subscriptions Plugin
Wenn man mögliche rechtliche Probleme ignoriert, gibt es bereits Online-Abonnementdienste, die wahrscheinlich verwendet werden könnten, um die Anforderungen des OP mit wenig bis gar keinem Code zu erfüllen. Zum Beispiel könnte ein Dienst wie Zapier als Vermittler zwischen einem Abonnementdienst und einem Discourse-Forum fungieren. Er könnte Benutzer basierend auf ihren Abonnements zu Discourse-Gruppen hinzufügen und daraus entfernen.
Ich bin sicher, dass dies auch mit einer Discourse/WordPress-Integration und etwas benutzerdefinierter Entwicklung erreicht werden könnte.
Nach meiner eigenen Recherche scheinen potenzielle rechtliche Probleme eher ein Stolperstein zu sein als die technischen Herausforderungen bei der Verwaltung von Gruppenmitgliedschaften basierend auf bezahlten Abonnements. Die Organisationen, die ich kenne und die diese Art von Dingen jetzt tun (Youtube, Paetron, Substack, X/Twitter), haben wahrscheinlich gute Rechtsteams.
Ich bin mir über die philosophischen Einwände gegen die Monetarisierung des Zugangs zu Gruppen/Kategorien nicht im Klaren.
3 „Gefällt mir“
Stripe ist die beste Plattform, die ich für so etwas kenne. Es gibt viele verschiedene Optionen, wie eine Gebühr für Steuern in verschiedenen Ländern kategorisiert werden kann.
Dies könnte funktionieren, wenn ein Ersteller regelmäßig Newsletter, Kunstwerke oder Videopräsentationen veröffentlicht. Es gibt verschiedene Optionen für Urheberrechte, entweder eingeschränkte oder bedingte Rechte.
Ich bin mir nicht sicher, ob das vom Thema abweicht oder genau auf den Punkt gebracht ist, aber meines Wissens fungiert Stripe nicht als Händler (Merchant of Record - MoR). Es gibt andere Online-Zahlungsabwickler, die als MoR fungieren. Ich überlasse es anderen, die Auswirkungen davon zu recherchieren. An diesem Punkt beginnt sich mein Kopf zu drehen und ich denke, dass die technischen Aspekte der Monetarisierung des Gruppenzugangs weitaus weniger einschüchternd sind als die rechtlichen Aspekte davon 
2 „Gefällt mir“
Ich bin nicht vertraut damit, was genau es bedeutet, wenn ein Zahlungsabwickler als „Merchant of Record“ fungiert. Sprechen Sie von einer Händler-Identifikationsnummer?
Es stimmt, dass ich diese bei Stripe nicht habe, nur eine verwirrende Kontonummer, die eine Mischung aus Zahlen und Buchstaben ist. Ein anderer Zahlungsabwickler, Elavon, gibt Händlern eine 10-stellige Händler-ID-Nummer, was bedeuten könnte, dass sie als Händler des Ausstellers fungieren, aber ich weiß nicht, was das bedeutet.
Beim ursprünglichen Thema der Monetarisierung des Zugangs zu einer Gruppe hängt es wirklich davon ab, worum es in der Gruppe geht oder wofür sie bestimmt ist. Mit einer Diskussionsseite könnte das sowohl für das Abonnieren dessen, was ein anderer Ersteller produziert, als auch für die Möglichkeit für Leute, ihr eigenes Material auf dem Forum eines anderen zu veröffentlichen, bedeuten.
Bei den Standard-Tier-Hostingkosten von 100 US-Dollar pro Monat ist dies erschwinglicher, wenn zehn Personen 10 US-Dollar pro Monat zahlen möchten, um Konten mit einem gehosteten Forum zu haben, das die Kosten deckt.
Andere Dienste wie Google Workspace kosten 7 US-Dollar pro Monat pro Benutzer, und geschäftliche E-Mails kosten im Allgemeinen etwa 13 US-Dollar pro Monat. Stripe oder eine andere Zahlungsplattform könnten verwendet werden, um Benutzergebühren dafür zu erheben, die keinen Gewinn generieren, sondern nur die Kosten für den Betrieb eines Gruppenkommunikationssystems decken.
Das ist eine gute Frage zur Website-Richtlinie. Für viele Websites wäre das wahrscheinlich nicht sinnvoll.
Oft gibt es Richtlinien gegen Eigenwerbung oder das Posten von Werbung, sodass jeder Versuch, von Dritten Verkäufe zu tätigen, wahrscheinlich von den meisten Administratoren verboten würde.
Gibt es in der Kategorie Marketplace für Meta nur Angebote für bezahlte Arbeit, und nicht für jemanden, der Geld für den Gruppenzugang verlangt oder versucht, Dienstleistungen gegen Bezahlung anzubieten oder etwas zu verkaufen?
Es gibt auch die Richtlinie, dass jedes Marktplatzangebot öffentlich und nicht in geschlossenen Nachrichten erfolgen muss, was eine gute Richtlinie zu sein scheint.
Das hier:
Ein Merchant of Record (MoR) ist eine juristische Person, die für den Verkauf von Waren oder Dienstleistungen an einen Endkunden verantwortlich ist. Sie wickelt alle Zahlungen ab und übernimmt die damit verbundenen Haftungsrisiken, wie z. B. die Erhebung der Umsatzsteuer, die Gewährleistung der PCI-Konformität (Payment Card Industry) sowie die Bearbeitung von Rückerstattungen und Rückbuchungen.
Was die Frage betrifft, warum es sinnvoll wäre, Gruppenbesitzern zu gestatten, Mitgliedschaften und den Zugang zu Discourse-Kategorien zu berechnen, so ist die offensichtlichste Antwort, dass die „Creator Economy“ riesig ist und Discourse das Potenzial hat, in diesem Bereich tätig zu sein. Bei der Creator Economy dreht sich alles um Gemeinschaft. Discourse ist ein Werkzeug zum Aufbau von Gemeinschaften, daher würde es gut in diesen Bereich passen.
Eine spekulativere Antwort ist, dass ich glaube, dass es einen Trend hin zu Crowdfunding und Patronage gibt, um Aktivitäten zu finanzieren, die außerhalb der normalen Creator Economy liegen.
Ein auf Discourse basierender Abonnementdienst auf Kategorieebene könnte auch der einfachste Weg sein, kostenloses Discourse-Hosting rentabel anzubieten. Ich gehe davon aus, dass der Forenbesitzer einen Anteil an den Gewinnen erhält. Substack ist ein gutes Modell dafür, wie das funktionieren könnte.
Der frühere Punkt in diesem Thema, dass Discourse die Dezentralisierung im Web fördern möchte, ist gültig. Aber es gibt einen möglichen Mittelweg. Discourse ist Open-Source-Software und verfügt über Werkzeuge, die den Export und Import von Kategorien ermöglichen. Ein Gruppenbesitzer in einem bestimmten Forum könnte die Möglichkeit erhalten, seine Community zu exportieren, wenn er dies wünscht. Ähnlich wie (aber einfacher als) der Inhaber eines physischen Geschäfts seinen Laden an einen neuen Standort verlegen kann.
1 „Gefällt mir“
PCI-Konformität ist sehr verwirrend und schwierig. Ich habe einige der Formulare dafür durchgesehen, als ich ein Händlerkonto bei meiner lokalen Bank eingerichtet habe. Deren Kartenlesegeräte verwenden ein geschlossenes verschlüsseltes System, was wahrscheinlich bedeutet, dass sie das rechtliche Risiko als MoR (Merchant of Record) übernehmen, was, wie ich glaube, korrekt ist, wenn Sie sagen, dass dies bei Stripe nicht der Fall ist.
Wenn jemand Zahlungsinformationen auf unabhängigen Servern verarbeitet, gibt es seitenweise Vorschriften mit allen Sicherheitsanforderungen zu beachten. Diese sind umfangreich und es drohen empfindliche Strafen bei Nichteinhaltung.
Das ist eine interessante Idee, ich bin mir nicht sicher, wie das gemacht werden könnte.
Manuell könnte ein neues Forum aus einem Backup des vorherigen gestartet werden, wobei alles außer der Kategorie, die jemand exportieren wollte, ausgeschlossen wird. Würde das funktionieren, oder gäbe es einen anderen Weg?
1 „Gefällt mir“
Discourse verfügt über Rake-Tasks zum Importieren und Exportieren von Kategorien und Gruppen: https://meta.discourse.org/t/administrative-bulk-operations/118349#exportimport-categories-10. Ich glaube nicht, dass dies zum Exportieren von Gruppen-PMs verwendet werden könnte, aber es würde den Import/Export von Gruppenmitgliedern und Gruppenaktivitäten, die in regulären Kategorien stattfanden, abwickeln.
Okay, gut zu wissen, dass es diese Funktion hat.