사용자가 다른 사용자에게 자신의 그룹 및 관련 그룹 자료에 대한 접근을 허용하는 대가로 수수료를 부과할 수 있나요? 사전에 제공되는 기능이 아니라는 점은 알고 있지만, 이런 기능이 가능한지 궁금합니다.
유료 그룹 멤버십(특정 카테고리에 대한 액세스 권한 부여)은 이미 존재하는 기능입니다. #plugins 채널을 확인해 보세요.
예시로 Patreon, Procourse Memberships, Subscriptia 등이 있습니다.
이미 이러한 멤버십을 관리하는 웹사이트가 있다면 SSO 페이로드를 통해 그룹 멤버십 정보를 전달할 수도 있습니다.
사용자가 소유하지 않은 사이트에서 다른 사용자에게 직접 비용을 청구할 수는 없는데, 그렇게 할 수 있는 것이 의미가 있을까요?
답변해 주셔서 감사합니다, @Stephen. 말씀해 주신 예시와 sso 옵션에 대해 알고 있습니다.
이것이 의미 있는 아이디어일까요? 어떤 것이든 의미가 있을 수 있습니다. 훌륭한 콘텐츠 크리에이터들이 모여 활발한 토론과 문제 해결을 하는 생동감 넘치는 포럼을 상상해 보세요. 하지만 동시에 유료 회원만 접근할 수 있는 비공개 그룹을 만들 수도 있습니다. 이렇게 하면 포럼 참가자들은 자신의 활동을 수익화할 수 있고, 포럼 운영자도 수익 분배/수수료를 통해 수익을 올릴 수 있습니다. 삼방 모두에게 이로운 Win-win-win 상황입니다.
이것이 가능한지 궁금할 뿐입니다. @angus, 일반적으로 (구체적인 견해를 구하는 것은 아닙니다) 이런 것이 가능한 것처럼 보입니까?
사람들을 태그하지 마세요.
여기서는 고려해야 할 많은 함의가 있으며, 코드를 작성하지 않고도 사용자가 서비스 제공자와 연결될 수 있는 예시들이 있습니다. 예를 들어 #marketplace에서는 사용자가 특별한 코드나 결제 처리 없이 컨설턴트와 연결됩니다.
이러한 유형의 거래를 관리하는 것은 매우 까다롭고 위험한 과정입니다. EU와 미국에서는 또한 많은 자금세탁법을 고려해야 합니다.
많은 사람들이 이런 아이디어를 떠올리지만, 결국 어떤 크리에이터든 월 5달러로 자신의 자체 Discourse를 구축하여 중간 수수료 없이 운영할 수 있습니다. 이는 훌륭한 일이며, Discourse의 핵심 목표 중 하나는 웹의 탈중앙화를 촉진하는 것입니다.
답변해 주셔서 감사합니다, @Falco. 실제로 크리에이터가 자신의 own 디스코르드를 시작할 수는 있지만, 여러 크리에이터가 하나의 디스코드에서 서로 소통하면서 유료로 전문 자료를 제공하면, 사람들이 먼저 해당 크리에이터를 찾을 수 있는 플랫폼이 만들어집니다. 바로 여기에 가치가 있을 것입니다. 이 유형의 기능이 불가능한 것 같다는 점을 파악했습니다. 피드백 주셔서 감사합니다!
이 기능은 완전히 구현할 수 있습니다. 물론, 이를 위한 개발 비용을 마련해야 합니다. ProCourse Memberships 💸 를 수정하여 사용자가 여러 "멤버십"을 구매할 수 있도록 하면 가능할 것 같습니다. 각 멤버십은 특정 그룹에 대한 접근 권한을 부여하고, 각 그룹은 특정 카테고리에 대한 접근 권한을 가집니다.
@Joshua_Kogan Custom Wizard 플러그인을 사용하여 지금 두 가지 다른 방법으로 이 작업을 수행할 수 있습니다.
외부에서 결제 처리
한 가지 방법은 커스텀 위자드의 한 단계 제출 시 사용자를 결제 제공업체로 보내고, 허용된 파라미터와 필수 데이터의 조합을 사용하여 결제가 완료되었는지 확인한 후, 다음 단계에서 사용자를 그룹에 추가하는 것입니다(“그룹에 추가” 동작 사용).
이 접근 방식의 결제 부분에 대한 전체 설명입니다. 그룹 추가 부분은 스스로 이해하기 쉬울 것입니다:
사용자를 결제 제공업체 설정으로 보내기
- Route To Action . 단계 제출 시 사용자를 대상 URL로 보내도록 하는 “Route To”라는 새로운 동작 유형이 있습니다. 위자드의 경우, 이 동작은 사용자의 결제 직전 단계에 추가되어야 합니다. 현재는 ‘payment’ 단계 자체에 추가되어 있지만, 이 단계를 제거하고 이전 단계에 추가할 수도 있습니다. Route To 동작에는 현재 두 가지 설정이 있습니다:
-
url: 대상 URL입니다. 다른 위자드 입력값과 마찬가지로, 위자드 필드를 위해
w{}를, 사용자 필드를 위해u{}를 사용하여 데이터를 보간할 수 있습니다. -
code: 대상 URL에 파라미터로 추가할 고유 코드입니다. 이 설정이 채워지면 커스텀 위자드는 고유한 무작위 16진수 문자열을 생성하여:
- 제공한 키를 사용하여 추가 쿼리 파라미터로 URL에 추가하고;
- 제공한 키를 사용하여 제출 데이터에 코드를 저장합니다.
각 요청에 고유한 키를 연결하면 해당 요청에 대한 모든 콜백(예: 사용자가 위자드로 돌아올 때)을 검증할 수 있습니다. Chargify의 경우, Chargify는 ‘reference’ 파라미터로 전송하는 모든 값을 저장합니다(자세히 보기). 이 값을 사용자가 결제를 완료한 후 Chargify가 사용자를 리다이렉트하는 ‘return url’에 추가할 수 있습니다.
-
Permitted Params . 이는 단계에서 허용되는 쿼리 파라미터와 제출 데이터에 저장될 때 사용할 키를 지정할 수 있는 새로운 단계 설정입니다. 이를 사용하여 통계나 분석 데이터(예: 사용자가 위자드에 진입한 위치)를 저장하거나 콜백을 처리할 수 있습니다. Chargify의 경우, 사용자가 결제를 완료하도록 Chargify로 리다이렉트할 때 ‘reference’ 코드를 Chargify에 전달하고(제출 데이터에 저장) 이 코드를 ‘return url’에 리턴 파라미터로 추가했습니다. 그런 다음 리턴 파라미터에서
customer_reference를 포함하는 것으로 지정한 파라미터를 추가하여 제출 데이터에 저장했습니다. Chargify에서는 ‘return url’을 ‘Route To’ 동작을 연결한 단계의 다음 단계 URL로 설정해야 한다는 점에 유의하십시오. 이는customer_reference파라미터를 해당 동일한 단계의 허용된 파라미터로 추가해야 함을 의미합니다. -
Required Data . 이는 사용자가 단계를 보기 전에 데이터 검사를 수행할 수 있는 새로운 단계 설정입니다. 현재는 제출 데이터의 한 부분이 다른 제출 데이터와 같도록 요구할 수 있습니다. 사용자가 단계를 로드하려고 할 때 필수 데이터 검사에 실패하면 오류 메시지가 표시됩니다. Chargify의 경우, “Route To” 동작에서 생성한 코드가 Chargify에서 반환된 customer_reference와 같도록 요구하는 데 이를 사용할 것입니다. 위자드 관리자에서 “데이터가 없을 때 표시할 메시지” 필드를 사용하여 사용자에게 표시되는 오류 메시지를 사용자 정의할 수 있습니다. 또한, 오류 메시지에 “위자드 재시작” 링크가 추가되어 사용자가 위자드를 1단계로 초기화하고 기존 입력값을 지울 수 있습니다.
내부에서 결제 처리
ProCourse 멤버십을 사용하여 결제를 받을 수 있습니다.
OAuth2 또는 Basic 인증(예: Stripe는 Basic 인증을 사용)을 지원하는 API가 있는 경우, 거의 모든 결제 제공업체를 사용할 수 있습니다. 이를 위해 Custom Wizard의 “Send to API” 동작과 관련 API 엔드포인트 관리 시스템을 사용하여 API 연결을 설정하면 됩니다. 설정 방법은 제공업체에 따라 다릅니다. 이 접근 방식은 덜 안정적이며 베타 단계의 기능이지만, 상당한 잠재력을 가지고 있습니다.
이것은 문제를 직접적으로 해결하지는 않지만, 꽤 유사합니다: Discourse Subscriptions Plugin
가능한 법적 문제를 무시한다면, 기존 온라인 구독 서비스를 사용하여 OP의 요구 사항을 거의 또는 전혀 코딩 없이 충족할 수 있을 것입니다. 예를 들어, Zapier와 같은 서비스가 구독 서비스와 Discourse 포럼 사이의 중개 역할을 할 수 있습니다. 이를 통해 사용자의 구독 상태에 따라 Discourse 그룹에서 사용자를 추가하거나 제거할 수 있습니다.
Discourse/WordPress 통합과 약간의 맞춤형 개발을 통해서도 이를 달성할 수 있을 것이라고 확신합니다.
직접 조사해 본 결과, 잠재적인 법적 문제가 유료 구독 기반 그룹 멤버십 관리의 기술적 도전보다 더 큰 걸림돌이 될 것 같습니다. 현재 이러한 일을 하고 있는 것으로 알려진 조직들(YouTube, Patreon, Substack, X/Twitter)은 아마도 훌륭한 법무팀을 갖추고 있을 것입니다.
그룹/카테고리 접근 권한을 수익화하는 것에 대한 철학적 반대에 대해서는 잘 모르겠습니다.
이 주제가 약간 벗어난 건지, 아니면 오히려 핵심을 짚는 건지 잘 모르겠는데, 제 이해로는 Stripe가 기록상 상인(Merchant of Record, MoR) 역할을 하지 않는 것 같습니다. MoR 역할을 수행하는 다른 온라인 결제 처리 업체들도 있습니다. 그로 인한 영향에 대해서는 다른 분들이 조사해 주시길 바랍니다. 여기부터는 제 머리가 어지러워지기 시작하고, 그룹 접근 권한을 수익화하는 기술적 측면은 법적 측면보다 훨씬 덜 intimidating(두렵거나 부담스러운) 것 같다는 생각이 듭니다 
결제 프로세서가 "Merchant of Record(기록상 상인)"로서 기능한다는 것이 정확히 무엇을 의미하는지 잘 모르겠습니다. Merchant Identification Number(상인 식별 번호)를 말씀하시는 건가요?
사실 Stripe에서는 해당 번호가 없고, 숫자와 문자가 섞인 복잡한 계정 번호만 있습니다. 다른 결제 프로세서인 Elavon은 상인에게 10자리 상인 ID를 제공하며, 이는 Merchant of Record로서 기능한다는 것을 의미할 수 있지만, 그 정확한 의미를 알지 못합니다.
원래 주제인 그룹 접근 권한의 수익화와 관련하여, 이것이 실제로 작동하려면 해당 그룹의 목적이나 성격에 크게 달려 있습니다. Discourse 페이지의 경우, 다른 크리에이터가 제작한 콘텐츠에 구독하는 것뿐 아니라, 다른 사람의 포럼에서 사람들이 자신만의 자료를 게시할 수 있는 기회까지 포함할 수 있습니다.
표준 티어 호스팅 비용이 월 100달러인 점을 고려하면, 10명이 월 10달러씩 지불하여 호스팅된 포럼에서 계정을 사용하는 경우 비용을 충당할 수 있으므로 더 경제적입니다.
Google Workspace와 같은 다른 서비스는 사용자당 월 7달러이며, 비즈니스 이메일은 일반적으로 월 13달러 정도입니다. Stripe 또는 다른 결제 플랫폼을 사용하여 이러한 사용자 비용을 수납할 수 있으며, 이는 이윤을 발생시키지 않고 그룹 커뮤니케이션 시스템을 운영하는 비용만 충당하는 데 사용됩니다.
이것은 좋은 사이트 정책 관련 질문입니다. 많은 사이트에서는 그럴 가능성이 낮을 것입니다.
자주 볼 수 있는 정책으로, 자사 홍보 금지나 광고 게시 금지가 있으며, 일반적으로 제3자의 모든 형태의 판매 시도는 대부분의 관리자에 의해 금지될 가능성이 높습니다.
Meta의 Marketplace 카테고리는 유료 작업 관련 제안 게시용으로만 사용되는 것으로 보이며, 그룹 접근을 위해 돈을 요구하거나 유료 서비스를 제공하거나 무언가를 판매하려는 사람은 포함되지 않는 것 같습니다.
또한 마켓플레이스 제안은 공개적으로 게시되어야 하며 폐쇄형 메시지에서 이루어져서는 안 된다는 정책도 있는데, 이는 좋은 정책인 것 같습니다.
다음과 같습니다:
Merchant of Record(MoR)는 최종 고객에게 상품 또는 서비스를 판매하는 데 대해 법적 책임을 지는 주체입니다. 이들은 모든 결제를 처리하고, 판매세 징수, 결제 카드 산업(PCI) 규정 준수, 환불 및 차지백 처리 등 관련 법적 책임을 부담합니다.
그룹 소유자가 그룹 가입비나 Discourse 카테고리 접근 권한에 대해 요금을 부과할 수 있도록 허용하는 것이 왜 합리적인지 묻는다면, 가장 명백한 이유는 크리에이터 경제가 거대하며 Discourse가 그 분야에서 운영될 잠재력이 있기 때문입니다. 크리에이터 경제의 핵심은 커뮤니티입니다. Discourse는 커뮤니티를 구축하는 도구이므로, 이 분야와 잘 어울립니다.
더 추측적인 답변을 드리자면, 일반 크리에이터 경제 범위를 벗어난 활동의 자금 조달을 위한 크라우드펀딩과 후원(patronage)에 대한 트렌드가 있다고 생각합니다.
Discourse 기반의 카테고리 수준 구독 서비스는 무료 Discourse 호스팅을 수익적으로 제공하는 가장 쉬운 방법이 될 수도 있습니다. 포럼 소유자가 수익의 일부를 가져갈 것이라고 가정합니다. Substack은 이것이 어떻게 작동할 수 있는 좋은 모델입니다.
이 토픽에서 앞서 언급된 Discourse가 웹의 탈중앙화를 촉진하려는 목표라는 점은 타당합니다. 하지만 가능한 중도안이 있습니다. Discourse는 오픈 소스 소프트웨어이며, 카테고리 내보내기 및 가져오기를 허용하는 도구를 갖추고 있습니다. 특정 포럼의 그룹 소유자가 원할 경우 커뮤니티를 내보낼 수 있는 권한을 부여할 수 있습니다. 이는 물리적 비즈니스 소유자가 매장을 새로운 위치로 이전하는 방식과 유사하지만(비슷하되 더 쉬운) 방법입니다.
PCI 준수(PCI compliance)는 매우 복잡하고 어렵습니다. 지역 은행에서 상인 서비스 계정을 설정할 때 관련 양식을 몇 가지 작성해 봤는데요. 해당 은행의 카드 리더는 폐쇄형 암호화 시스템을 사용하는데, 이는 법적 리스크를 Merchant of Record(MoR, 기록상 상인)가 부담한다는 것을 의미할 가능성이 높습니다. 스트라이프(Stripe)의 경우 그렇지 않다고 말씀하신 것은 옳다고 생각합니다.
독립 서버에서 결제 카드 정보를 처리하는 경우, 모든 보안 요구사항을 포함해 규정을 수십 페이지에 걸쳐 검토해야 합니다. 이러한 규정은 매우 엄격하며, 미준수 시 막대한 벌금이 부과됩니다.
흥미로운 아이디어인데, 이것이 어떻게 가능할지 잘 모르겠습니다.
수동적으로 이전 포럼의 백업에서 새 포럼을 시작하고, 내보내고 싶은 카테고리 외에는 모든 것을 제외하는 방식이라면 어떻게 될까요? 이렇게 하면 될까요, 아니면 다른 방법이 있을까요?
Discourse에는 카테고리와 그룹을 가져오고 내보내는 rake 작업이 있습니다: https://meta.discourse.org/t/administrative-bulk-operations/118349#exportimport-categories-10. 그룹의 개인 메시지(PM)를 내보내는 데에는 사용할 수 없다고 생각하지만, 일반 카테고리에서 발생한 그룹 멤버의 가져오기/내보내기 및 그룹 활동은 처리할 수 있습니다.
아, 알겠습니다. 그런 기능이 있다는 건 좋네요.