É possível que os usuários cobrem uma taxa para permitir que outros usuários acessem seus grupos e materiais relacionados? Sei que não é uma funcionalidade pronta, mas é possível?
A associação paga a grupos (que por sua vez concede acesso a categorias específicas) é um recurso existente. Dê uma olhada em #plugins
Exemplos incluem Patreon, Procourse Memberships e Subscriptia.
Se você já possui um site que gerencia esse tipo de associação, também pode fornecer informações de associação a grupos por meio da sua carga útil SSO.
Os usuários não podem cobrar taxas diretamente de outros em um site que não possuem; faria sentido que eles sequer pudessem fazer isso?
Obrigado pela resposta, @Stephen. Estou ciente dos exemplos que você incluiu, bem como da opção de SSO.
Faria sentido? Tudo pode fazer sentido. Imagine um fórum animado com ótimos criadores de conteúdo se reunindo para discutir e resolver problemas; no entanto, eles também poderiam criar grupos privados acessíveis apenas a membros pagantes. Dessa forma, os participantes do fórum poderiam monetizar sua atividade no fórum, e o proprietário do fórum poderia monetizar com uma divisão/comissão. Ganha-ganha-ganha.
Estou apenas curioso se isso é possível. @angus, de modo geral (não estou procurando uma cotação aqui), algo assim parece possível?
Por favor, não marque pessoas.
Há muitas implicações a serem consideradas aqui, bem como exemplos de como os usuários podem ser conectados a prestadores de serviços sem a necessidade de escrever qualquer código. Tome o Marketplace como exemplo: os usuários são conectados a consultores sem a necessidade de código especial ou processamento de pagamentos.
Gerenciar esse tipo de transação é um processo muito delicado e arriscado. Na UE e nos EUA, você também precisa considerar as diversas leis contra lavagem de dinheiro.
Muitas pessoas têm essa ideia, mas, no final, qualquer criador pode ter seu próprio Discourse por US$ 5 por mês e evitar a taxa do intermediário. O que é ótimo, pois uma das missões centrais do Discourse é promover a descentralização na web.
Obrigado pela resposta, @Falco. De fato, os criadores podem iniciar seu próprio discourse; no entanto, ter um único discourse com vários criadores discutindo entre si e, em seguida, oferecendo materiais especializados mediante taxa, criaria uma plataforma que permite que as pessoas encontrem o criador em primeiro lugar. Esse seria o valor. Estou entendendo que esse tipo de funcionalidade não é possível. Obrigado pelo feedback!
A funcionalidade é totalmente possível. Obviamente, será necessário financiar o seu desenvolvimento. Acredito que com US$ 10 mil é possível modificar ProCourse Memberships 💸 para que existam múltiplas “assinaturas” que os membros possam adquirir. Cada assinatura concede acesso a um grupo, e cada grupo, acesso a uma categoria.
@Joshua_Kogan Você pode fazer isso agora mesmo de duas maneiras diferentes usando o plugin Custom Wizard.
Processar pagamento externamente
Um método seria enviar o usuário para um provedor de pagamento ao finalizar um passo de um assistente personalizado, garantir que o pagamento seja concluído usando uma combinação de parâmetros permitidos e dados obrigatórios e, em seguida, adicionar o usuário a um grupo em um passo subsequente (usando a ação “Adicionar ao Grupo”).
Esta é uma descrição completa da parte de pagamento dessa abordagem. A parte de adicionar ao grupo deve ser autoexplicativa:
Configuração para enviar usuário ao provedor de pagamento
- Rotear para Ação. Há um novo tipo de ação chamado “Rotear para” que permite enviar um usuário a uma URL de destino ao finalizar um passo. Para seus assistentes, a ação deve ser adicionada ao passo que antecede o pagamento do usuário. Atualmente, elas são adicionadas ao próprio passo de “pagamento”, mas você pode remover esse passo e adicioná-las ao passo anterior, se preferir. A ação “Rotear para” atualmente possui duas configurações:
-
url: Esta é a URL de destino. Como em outras entradas de assistente, você pode interpolar dados usando w{} para campos do assistente e u{} para campos do usuário.
-
code: Um código exclusivo para adicionar como parâmetro à URL de destino. Quando essa configuração é preenchida, o Custom Wizard gera uma string hexadecimal aleatória única que:
- adiciona à URL como um parâmetro de consulta adicional usando a chave que você fornece; e
- salva o código nos dados de submissão usando a chave que você fornece
Associar uma chave única a cada solicitação permite que qualquer callback para essa solicitação (ou seja, quando o usuário retorna ao assistente) seja validado. No caso do Chargify, o Chargify armazenará qualquer valor que você enviar no parâmetro ‘reference’ (veja mais), que você poderá então adicionar à ‘URL de retorno’ para onde o Chargify redireciona o usuário após ele concluir o pagamento.
-
Parâmetros Permitidos. Esta é uma nova configuração de passo que permite especificar quais parâmetros de consulta são permitidos para o passo e a chave com a qual eles devem ser salvos nos dados de submissão. Você pode usá-lo tanto para salvar dados estatísticos ou analíticos (como de onde o usuário entrou no assistente) quanto para callbacks. No caso do Chargify, passamos o código ‘reference’ para o Chargify (e o salvamos nos dados de submissão) ao redirecionar o usuário para o Chargify para concluir o pagamento. Em seguida, adicionaríamos esse código à ‘URL de retorno’ como um parâmetro de retorno, que então salvamos nas submissões adicionando qualquer parâmetro que especificarmos como contendo o
customer_referencenos parâmetros de retorno. Observe que no Chargify você precisará definir a ‘URL de retorno’ como a URL do passo após o passo ao qual você anexou a ação ‘Rotear para’. Isso significa que você estará adicionando o parâmetrocustomer_referencecomo um parâmetro permitido a esse mesmo passo. -
Dados Obrigatórios. Esta é uma nova configuração de passo que permite impor uma verificação de dados antes de permitir que um usuário visualize o passo. Atualmente, você pode exigir que uma parte dos dados de submissão seja igual a outra parte dos dados de submissão. Se o usuário tentar carregar o passo e a verificação de dados obrigatórios falhar, ele verá uma mensagem de erro. No caso do Chargify, usaremos isso para exigir que o código que criamos na ação “Rotear para” seja igual ao
customer_referenceretornado pelo Chargify. Você pode personalizar a mensagem de erro exibida aos usuários usando o campo “Mensagem exibida quando os dados não estão presentes” no administrador do assistente. Além disso, há um link “Reiniciar Assistente” anexado à mensagem de erro, permitindo que o usuário redefina o assistente para o passo 1 e limpe as entradas existentes.
Processar pagamento internamente
Você pode usar o ProCourse Memberships para processar pagamentos.
Você também pode usar quase qualquer provedor de pagamento, desde que eles tenham uma API que suporte OAuth2 ou autorização básica (o Stripe, por exemplo, usa autorização básica), configurando uma conexão de API usando a ação “Enviar para API” do Custom Wizard e o sistema de gerenciamento de endpoints de API associado. Como você configurará isso dependerá do provedor. Essa abordagem é menos estável; é um recurso em fase beta, mas tem potencial significativo.
Isso não resolve o problema diretamente, mas está próximo: Discourse Subscriptions Plugin
Ignorando possíveis questões legais, existem serviços de assinatura online existentes que provavelmente poderiam ser usados para atender aos requisitos do OP com pouco ou nenhum código. Por exemplo, um serviço como o Zapier poderia atuar como intermediário entre um serviço de assinatura e um fórum Discourse. Ele poderia adicionar e remover usuários de grupos Discourse com base em suas assinaturas.
Tenho certeza de que isso também poderia ser alcançado com integração Discourse/WordPress e um pouco de desenvolvimento personalizado.
Pelo que investiguei, parece que as potenciais questões legais podem ser um obstáculo maior do que os desafios técnicos de gerenciar associações de grupos com base em assinaturas pagas. As organizações que conheço que estão fazendo esse tipo de coisa agora (Youtube, Paetron, Substack, X/Twitter) provavelmente têm boas equipes jurídicas.
Não tenho certeza sobre as objeções filosóficas à monetização do acesso a grupos/categorias.
O Stripe é a melhor plataforma que conheço para algo assim, existem muitas opções diferentes sobre como categorizar uma taxa para impostos em diferentes países.
Isso poderia funcionar se um criador estiver publicando consistentemente newsletters, obras de arte ou apresentações em vídeo. Existem diferentes opções para direitos autorais, que podem ser direitos limitados ou condicionais.
Não tenho certeza se isso está saindo do tópico, ou exatamente no tópico, mas entendo que a Stripe não funciona como a Merchant of Record (MoR). Existem outros processadores de pagamento online que funcionam como MoR. Deixo para outros pesquisarem as implicações disso. Este é o ponto em que minha cabeça começa a girar e começo a pensar que os aspectos técnicos de monetizar o acesso a grupos são muito menos assustadores do que os aspectos legais deles 
Não estou familiarizado com o que exatamente significa para um processador de pagamentos funcionar como um “Merchant of Record” (Comerciante Registrado), você está falando de um Merchant Identification Number (Número de Identificação do Comerciante)?
É verdade que não tenho isso com a Stripe, apenas um número de conta confuso que é uma mistura de números e letras. Outro processador de pagamentos, Elavon, dá aos comerciantes um ID de comerciante de 10 dígitos, o que pode significar que eles atuam como Merchant of Record, mas não sei o que isso significa.
Com o tópico original de monetizar o acesso a um grupo, para que isso funcione realmente depende do que é o grupo ou para quê, com uma página de discussão isso pode significar tanto para assinar o que outro criador está produzindo quanto a oportunidade para as pessoas publicarem seu próprio material no fórum de outra pessoa.
Com o plano de hospedagem padrão custando US$ 100 por mês, isso é mais acessível se dez pessoas quiserem pagar US$ 10 por mês para ter contas em um fórum hospedado que cubra o custo.
Outros serviços como o Google Workspace custam US$ 7 por mês por usuário e o e-mail comercial geralmente custa cerca de US$ 13 por mês, a Stripe ou outra plataforma de pagamento poderia ser usada para coletar taxas de usuário para isso, que não geram lucro, mas apenas cobrem o custo para executar um sistema de comunicação em grupo.
Esta é uma boa pergunta sobre a política do site, para muitos sites provavelmente não faria sentido.
Muitas vezes existem políticas de não auto-promoção ou postagem de publicidade, então, geralmente, qualquer tipo de tentativa de vendas por terceiros provavelmente seria proibida pela maioria dos administradores.
Com a categoria Marketplace para Meta, parece que é apenas para postar ofertas de trabalho pago, não para alguém pedindo dinheiro pelo acesso a um grupo ou tentando oferecer serviços pagos ou vender algo?
Há também a política de que qualquer oferta de marketplace deve ser pública e não em mensagens fechadas, o que parece ser uma boa política.
Isso:
Um Merchant of Record (MoR) é uma entidade legal responsável por vender bens ou serviços a um cliente final. Eles lidam com todos os pagamentos e assumem as responsabilidades associadas, como a coleta de impostos sobre vendas, garantia de conformidade com o Padrão de Segurança de Dados da Indústria de Cartões de Pagamento (PCI) e o processamento de reembolsos e estornos.
Em termos de por que faria sentido permitir que os proprietários de grupos cobrassem por assinaturas de grupos e acesso a categorias do Discourse, a resposta mais óbvia é porque a economia do “criador” é enorme e o Discourse tem o potencial de operar nesse espaço. A economia do criador é sobre comunidade. O Discourse é uma ferramenta para construir comunidades, então seria uma boa opção para o espaço.
Uma resposta mais especulativa é que acredito que há uma tendência em direção ao crowdfunding e ao patrocínio para financiar atividades que ficam fora da economia normal do criador.
Um serviço de assinatura baseado em Discourse, em nível de categoria, também pode ser a maneira mais fácil de fornecer hospedagem gratuita de Discourse de forma lucrativa. Estou assumindo que o proprietário do fórum receberia uma parte dos lucros. O Substack é um bom modelo de como isso poderia funcionar.
O ponto levantado anteriormente neste tópico de que o Discourse visa promover a descentralização na web é válido. Mas há um possível meio-termo. O Discourse é um software de código aberto e possui ferramentas que permitem exportar e importar categorias. Um proprietário de grupo em um fórum específico poderia ter a capacidade de exportar sua comunidade, se assim desejasse. Semelhante a (mas mais fácil do que) a maneira como o proprietário de um negócio físico pode mudar sua loja para um novo local.
A conformidade com PCI é muito confusa e difícil. Passei por alguns dos formulários para isso quando configurei uma conta de serviço de comerciante com o banco local. Os leitores de cartão deles usam um sistema criptografado fechado, o que provavelmente significa que eles assumem o risco legal de serem um MoR, o que acredito que você esteja correto ao dizer que não é o caso da Stripe.
Se alguém estiver processando informações de cartão de pagamento em servidores independentes, há páginas e páginas de regulamentos para analisar com todos os requisitos de segurança, que são pesados e há multas altas por falhas.
Esta é uma ideia interessante, não tenho certeza de como isso poderia ser feito.
Manualmente, um novo fórum poderia ser iniciado a partir do backup anterior, excluindo tudo, exceto a categoria que alguém gostaria de exportar. Isso funcionaria, ou haveria alguma outra maneira?
O Discourse tem tarefas rake para importar e exportar categorias e grupos: https://meta.discourse.org/t/administrative-bulk-operations/118349#exportimport-categories-10. Não acredito que isso possa ser usado para exportar MPs de grupo, mas lidaria com a importação/exportação de membros de grupo e atividades de grupo que ocorreram em categorias regulares.
Ah, ok, bom saber que tem essa capacidade.