이것이 사용자 사용자 정의 필드의 사용 사례인가요?

사용자들이 서브포럼을 생성할 수 있도록 하는 방법을 알아보고 있습니다. 슬랙 채널처럼 작동하도록 말이죠.

제안 중 하나는 태그를 사용하는 것이었습니다. 즉, 사용자가 태그를 생성하거나(또는 제가 만든 앱이 API를 통해 생성) 해당 태그의 페이지가 서브포럼의 페이지처럼 기능하도록 하는 방식입니다.

그렇다면 그 서브포럼에 속한 멤버만 해당 서브포럼에 게시물을 올릴 수 있도록 하는 방법은 무엇일까요? 다시 말해, 그 서브포럼의 멤버만 자신의 게시물에 해당 서브포럼의 태그를 연결할 수 있도록 하는 것입니다.

이를 위해 "사용자 사용자 정의 필드(user custom fields)"를 활용할 수 있는 방법이 있을까요? 특정 태그로 게시물을 올릴 수 있는 권한이 있는 사용자를 표시하는 방식으로 사용할 수 있을까요?

사용자 사용자 정의 필드가 정확히 어떤 용도로 사용되는지 잘 이해하지 못해서, 더 자세히 알고 싶습니다.

태그에는 사용자 수준의 권한이 제공되지 않는다고 생각합니다. 대신 카테고리를 확인해 보시는 것이 좋습니다.

Discourse는 그룹과 카테고리를 사용하여 콘텐츠 접근을 제어합니다. 자세한 내용은 이 토픽의 영상을 참고하세요: 카테고리 보안 설정을 사용하여 비공개 카테고리를 만드는 방법

답변해 주셔서 감사합니다. 카테고리 방식이 더 쉬운 방법이라는 데 동의합니다. 하지만 이 경우 사용자가 대량으로 생성할 수 있는 서브포럼이 될 것입니다. 서브포럼은 앱의 핵심 요소이므로 사용자 기반이 성장함에 따라 수백 개, 혹은 그 이상으로 늘어날 수 있습니다.

수백 개에서 수천 개의 카테고리를 생성하면 큰 문제가 된다는 이야기를 들었기 때문에 다른 해결책을 찾아야 한다고 합니다. 다른 제안이 있으신가요? API와 상호작용하는 별도 앱을 구축하는 것도 기꺼이 시도해 보겠습니다. 제가 Discourse에서 특히 원하는 핵심 기능은 뛰어난 게시물/답변/태그 기능입니다.

원하시는 것은 Discourse가 지향하는 방향과는 맞지 않습니다.

사용자가 직접 서브레딧/서버를 만들어 소유할 수 있고, 플랫폼의 통제와 수익화는 운영자가 유지하는 Reddit/Discord 형태의 플랫폼을 원하시는 것 같습니다.

반면 Discourse는 정반대의 방향을 지향하며, 각 서브레딧/서버/길드가 독립적인 사이트로 운영되고, 데이터를 소유하며, 고유한 URL에서 운영되도록 합니다.

오픈소스 프로젝트를 크게 개조하는 것은 가능하지만, 원하시는 방향에 더 가까운 다른 도구를 사용하는 것을 권장합니다.

이것이 일반적인 사용 사례가 아니라는 점은 잘 알고 있지만, Discourse가 정말 훌륭하기 때문에 이걸 Discourse로 구현할 수 있는 방법을 꼭 찾아보고 싶습니다. 어느 정도는 근접할 수 있습니다. API를 통해 태그를 생성하고, 그 태그 페이지가 서브포럼 페이지처럼 작동하도록 사용자를 해당 태그 페이지로 유도하는 방식이죠. 제가 빠져 있는 핵심 부분은 해당 태그로 게시물을 작성할 수 있는 사용자를 제한하는 기능입니다.

Discord는 앱 통합에 제한이 있어서 이 용도로는 적합하지 않습니다. Reddit을 앱과 어떻게 통합할 수 있는지에 대해서는 잘 모르겠습니다.

질문자님은 이걸 실제로 Reddit으로 구현할 수 있다는 건지, 아니면 제가 원하는 기능의 '유형’이 Reddit과 비슷하다는 의미였는지 궁금합니다.

어쨌든, 제가 보기에는 Discourse의 핵심 장점은 채팅이 아니라 포럼이라는 점입니다. 그리고 제가 여기에서 원하는 것이 바로 포럼과 같은 기능입니다. 이 측면에서 Discourse의 대안을 아직 찾지 못했지만, 제안을 열려 있습니다.

해당 핵심 기능은 로드맵에 포함되어 있지 않으며, 추가할 계획도 없습니다.

수년 동안 이 주제에 대해 많은 토론이 있었습니다:

그 내용을 확인했습니다. 여기서의 차이는, 사용자가 소그룹을 생성하는 경험을 제공하기 위해 완전히 독립적인 앱을 구축하고, 그 앱이 Discourse API와 상호작용하도록 하는 방식에 대해 기꺼이 진행할 수 있다는 점입니다. 즉, 별도의 앱에서 소그룹을 직접 생성하고, 멤버를 연결하는 등의 작업을 수행할 수 있습니다.

하지만 제 앱이 생성한 해당 서브포럼 페이지에서 Discourse의 프론트엔드 게시 기능(주제 생성, 답변 작성, 카테고리 링크, 태그 추가 등)을 여전히 사용하고자 합니다.

사용자 커스텀 필드를 태그와 연결하여 사용자가 게시할 수 있는 태그를 제한하는 방법이 있다고 들었습니다.

결국 제가 언급한 바와 같이, 서브포럼 설정의 상당 부분을 제 앱 측에서 처리할 수 있지만, Discourse의 게시 기능을 그대로 활용할 수 있다면 시간을 많이 절약할 수 있을 것입니다.

답변해 주신 모든 분들께 감사드립니다. 사용자 커스텀 필드가 일반적으로 어떻게 사용되는지에 대한 예시를 공유해 주실 수 있으신가요?

허용된 각 사용자에게 해당 서브포럼(예: ‘subforum123’)과 관련된 커스텀 필드를 추가한 뒤, 사용자가 서브포럼 페이지에 접속할 때 API를 호출하여 해당 사용자가 필요한 커스텀 필드를 가지고 있는지 확인하는 방식으로 구현할 수 있을 것 같습니다. 만약 해당 필드가 있으면 게시글 작성과 답변이 가능하도록 하고, 없으면 불가능하도록 하며, 이 경우 '새 주제’와 ‘답변’ 버튼을 숨기는 방식으로 처리할 수 있을 것 같습니다.

일반적으로 가입 시 정보(위치, 직책 등)를 수집하는 데 사용되며, 이 정보는 프로필 카드에 표시됩니다.

원하시는 것이 아마도 사람들이 자체 디스코urs(예: username.yoursite.com)를 생성할 수 있도록 하는 것일 수 있습니다. 이 디스코urs는 ‘홈’ 디스코urs를 사용자 하위 사이트의 SSO 서버로 사용하는 멀티사이트 설치 환경에서 실행됩니다. 새로운 사용자가 생성될 때마다 새로운 username.yoursite.com 디스코urs 사이트를 생성하는 플러그인을 만들 수도 있을 것입니다. 하지만 모든 사용자가 자신의 서브포럼을 원하지는 않을 수 있으므로, 대신 사용자가 자신의 하위 사이트를 생성할 수 있게 해주는 . . . 무언가 . . .가 필요할 것입니다.

그것이 여러분이 하려는 것에 점점 더 가까워지는 것 같습니다.

실제로 제가 생각했던 것(즉, “서브포럼”)에 꽤 근접한 것 같습니다. 감사합니다. 멀티사이트(multisite)에 대해 더 자세히 알아볼게요.

멀티사이트 구조에서 사용자가 자체 서브사이트를 만들 수 있도록 허용하는 것은, 예를 들어 사용자가 자체 카테고리를 만들 수 있도록 허용하는 것보다 훨씬 더 많은 리소스를 소모할 것 같다는 생각이 들었습니다. 수백 개 이상의 서브사이트가 있는 멀티사이트가 제대로 동작할 수 있을까요? 서버에 얼마나 많은 부하가 걸릴지 궁금합니다. 아니면 아마도 트래픽이 많은 단일 사이트와 비교했을 때 부하가 크게 더 많지는 않을 수도 있겠죠?

그렇습니다. 하지만 가능하다는 이점이 있습니다.

네, 월 100~300달러에 두 가지 이상의 다른 플러그인 세트를 사용하여 수 개 이상의 서브사이트를 운영하는 회사를 적어도 한 곳 알고 있습니다. 다른 회사들은 사이트당 월 20달러를 청구합니다.

명확하지 않을 수 있으니 말씀드리자면, 기본적으로 여러분은 Discourse 호스팅 회사를 구축하고 있는 것입니다.

수십 개의 사이트를 시작하려면 4~16GB의 RAM이 필요할 것입니다.

확인해 보면, 그 회사가 서브사이트 수백 개를 유지하기 위해 월 100달러에서 300달러를 지불한다는 말씀이신가요? (그렇게 말씀하시는 것 같네요. 서브사이트 수백 개에 비해 꽤 적은 금액입니다)

내 말은, 한 회사(디스코urses를 개발하는 회사)가 여러분이 만들고자 하는 사이트당 100달러~300달러를 청구한다는 것입니다. 다른 회사들은 월 20달러 수준의 요금을 부과하고 있는데, 아마도 그들은 돈을 잘 벌고 있을 것입니다.

제가 제안한 문제를 해결하는 데에는 적어도 100시간은 걸릴 것입니다. 아마도 더 걸릴 수도 있고요.

수정: 하지만 단순히 단일 멀티사이트만 원하신다면 그보다 적은 시간 안에 시작할 수 있을지도 모릅니다.

네, 알겠습니다. 정보 감사합니다.