Ist es möglich, dass Nutzer eine Gebühr erheben, um anderen Nutzern den Zugang zu ihren Gruppen und den damit verbundenen Gruppenmaterialien zu gewähren? Ich weiß, dass dies keine Standardfunktion ist, aber ist es überhaupt möglich?
Eine kostenpflichtige Gruppenmitgliedschaft (die ihrerseits den Zugang zu bestimmten Kategorien gewährt) ist eine bestehende Funktion. Schauen Sie sich dazu den Kanal #plugins an.
Beispiele hierfür sind Patreon, Procourse Memberships und Subscriptia.
Wenn Sie bereits eine Website betreiben, die solche Mitgliedschaften verwaltet, können Sie die Informationen zur Gruppenmitgliedschaft auch über Ihre SSO-Nutzlast bereitstellen.
Können Nutzer auf einer Website, die sie nicht besitzen, andere direkt Gebühren in Rechnung stellen? Wäre es überhaupt sinnvoll, ihnen diese Möglichkeit einzuräumen?
Danke für die Antwort, @Stephen. Mir sind die von dir genannten Beispiele sowie die SSO-Option bekannt.
Würde das Sinn ergeben? Alles kann Sinn ergeben. Stell dir ein lebendiges Forum vor, in dem großartige Content-Ersteller zusammenkommen, um zu diskutieren und Probleme zu lösen. Gleichzeitig könnten sie private Gruppen erstellen, auf die nur zahlende Mitglieder zugreifen können. Auf diese Weise könnten die Forumsteilnehmer ihre Aktivitäten im Forum monetarisieren, und der Forum-Betreiber könnte über eine Aufteilung oder Provision verdienen. Ein Gewinn für alle drei Parteien.
Ich bin nur neugierig, ob das möglich ist. @angus, allgemein gesprochen (ich suche hier keine Zusage), scheint so etwas machbar zu sein?
Bitte markieren Sie keine Personen.
Hier gibt es viele Aspekte zu berücksichtigen, sowie Beispiele dafür, wie Nutzer mit Dienstleistern verbunden werden können, ohne Code zu schreiben. Nehmen wir das #marketplace-Beispiel: Nutzer werden mit Beratern verbunden, ohne dass spezieller Code oder Zahlungsabwicklung erforderlich ist.
Die Verwaltung solcher Transaktionen ist ein sehr heikler und riskanter Prozess. Innerhalb der EU und der USA müssen zudem die zahlreichen Gesetze zur Geldwäsche beachtet werden.
Viele Menschen haben diese Idee, aber am Ende kann jeder Ersteller sein eigenes Discourse-Forum für 5 Dollar im Monat betreiben und die Gebühren für den Mittelsmann umgehen. Das ist eine großartige Sache; einer der Kernziele von Discourse ist es, die Dezentralisierung im Web zu fördern.
Danke für die Antwort, @Falco. Tatsächlich können Creator ihre eigenen Discourses starten; jedoch würde eine einzige Discourse, in der viele Creator miteinander diskutieren und dann spezialisierte Materialien gegen Gebühr anbieten, eine Plattform schaffen, die es Menschen ermöglicht, den Creator überhaupt erst zu finden. Das wäre der Mehrwert. Ich gehe davon aus, dass diese Art von Funktionalität nicht möglich ist. Danke für das Feedback!
Die Funktionalität ist grundsätzlich möglich. Natürlich müssen Sie die Entwicklung finanzieren. Meiner Einschätzung nach reicht ein Budget von 10.000 US-Dollar, um eine angepasste Version von ProCourse Memberships 💸 zu erstellen, die mehrere „Mitgliedschaften
@Joshua_Kogan Du kannst dies sofort auf zwei verschiedene Arten mit dem Custom-Wizard-Plugin umsetzen.
Zahlung extern abwickeln
Eine Möglichkeit besteht darin, den Nutzer nach Absenden eines Schritts eines benutzerdefinierten Wizards zu einem Zahlungsanbieter weiterzuleiten, die Zahlung mithilfe einer Kombination aus erlaubten Parametern und erforderlichen Daten sicherzustellen und den Nutzer anschließend in einem folgenden Schritt einer Gruppe hinzuzufügen (unter Verwendung der Aktion „Zu Gruppe hinzufügen“).
Dies ist eine vollständige Beschreibung des Zahlungsaspekts dieses Ansatzes. Der Teil „Zu Gruppe hinzufügen“ sollte selbsterklärend sein:
Einrichtung: Nutzer zum Zahlungsanbieter weiterleiten
- Zu Aktion routen . Es gibt einen neuen Aktionstyp namens „Zu … routen“, mit dem du einen Nutzer nach Absenden eines Schritts zu einer Ziel-URL weiterleiten kannst. Für deine Wizards sollte die Aktion zu dem Schritt hinzugefügt werden, der dem Zahlungsschritt des Nutzers vorausgeht. Derzeit werden sie dem Schritt „Zahlung“ selbst hinzugefügt, du kannst diesen Schritt jedoch entfernen und die Aktion stattdessen dem vorhergehenden Schritt hinzufügen. Die Aktion „Zu … routen“ verfügt derzeit über zwei Einstellungen:
-
url: Dies ist die Ziel-URL. Wie bei anderen Wizard-Eingaben kannst du Daten interpolieren, wobei w{} für Wizard-Felder und u{} für Benutzerfelder steht.
-
code: Ein eindeutiger Code, der als Parameter zur Ziel-URL hinzugefügt wird. Wenn diese Einstellung ausgefüllt ist, generiert der benutzerdefinierte Wizard einen eindeutigen zufälligen Hex-String, der:
- als zusätzlicher Abfrageparameter zur URL mit dem von dir bereitgestellten Schlüssel hinzugefügt wird; und
- im Absendedaten unter dem von dir bereitgestellten Schlüssel gespeichert wird
Die Verknüpfung eines eindeutigen Schlüssels mit jeder Anfrage ermöglicht die Validierung eines beliebigen Callbacks für diese Anfrage (d. h. wenn der Nutzer zum Wizard zurückkehrt). Im Fall von Chargify speichert Chargify jeden Wert, den du im Parameter „reference“ sendest (weitere Informationen), den du dann zur „Rückgabe-URL“ hinzufügen kannst, zu der Chargify den Nutzer nach Abschluss der Zahlung weiterleitet.
-
Erlaubte Parameter . Dies ist eine neue Schritteinstellung, mit der du angeben kannst, welche Abfrageparameter für den Schritt erlaubt sind und unter welchem Schlüssel sie in den Absendedaten gespeichert werden sollen. Du kannst dies verwenden, um sowohl statistische oder analytische Daten zu speichern (z. B. woher der Nutzer den Wizard betreten hat) als auch für Callbacks. Im Fall von Chargify haben wir den „reference“-Code an Chargify übergeben (und in den Absendedaten gespeichert), als wir den Nutzer zur completion der Zahlung zu Chargify weitergeleitet haben. Wir würden diesen Code dann als Rückgabeparameter zur „Rückgabe-URL“ hinzufügen, den wir dann in den Einreichungen speichern, indem wir den Parameter, der
customer_referenceenthält, zu den Rückgabeparametern hinzufügen. Beachte, dass du bei Chargify die „Rückgabe-URL“ auf die URL des Schritts nach dem Schritt setzen musst, an dem du die Aktion „Zu … routen“ angehängt hast. Das bedeutet, dass du dencustomer_reference-Parameter als erlaubten Parameter zu diesemselben Schritt hinzufügen musst. -
Erforderliche Daten . Dies ist eine neue Schritteinstellung, mit der du vor dem Anzeigen eines Schritts eine Datenprüfung erzwingen kannst. Derzeit kannst du verlangen, dass ein Teil der Absendedaten einem anderen Teil der Absendedaten entspricht. Wenn der Nutzer versucht, den Schritt zu laden und die erforderliche Datenprüfung fehlschlägt, wird eine Fehlermeldung angezeigt. Im Fall von Chargify verwenden wir dies, um zu verlangen, dass der Code, den wir in der Aktion „Zu … routen“ erstellt haben, dem von Chargify zurückgegebenen
customer_referenceentspricht. Du kannst die den Nutzern angezeigte Fehlermeldung über das Feld „Nachricht anzeigen, wenn Daten nicht vorhanden“ im Wizard-Admin anpassen. Zusätzlich wird der Fehlermeldung ein Link „Wizard neu starten“ angehängt, mit dem der Nutzer den Wizard auf Schritt 1 zurücksetzen und vorhandene Eingaben löschen kann.
Zahlung intern abwickeln
Du kannst ProCourse-Mitgliedschaften verwenden, um Zahlungen entgegenzunehmen.
Du kannst auch fast jeden Zahlungsanbieter verwenden, sofern dieser eine API unterstützt, die OAuth2 oder die Basisauthentifizierung unterstützt (Stripe verwendet beispielsweise die Basisauthentifizierung), indem du eine API-Verbindung über die Aktion „An API senden“ des Custom Wizards und das zugehörige API-Endpoint-Management-System einrichtest. Wie du dies einrichtest, hängt vom Anbieter ab. Dieser Ansatz ist weniger stabil; es handelt sich um eine Beta-Funktion, hat aber erhebliches Potenzial.
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.
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 
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.
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?
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.