네, 하지만 그건 방대하고 비용이 많이 드는 플러그인이 될 거예요.
1개의 좋아요
SSO 또는 LDAP를 사용하면 모든 사용자를 하나의 도메인 로그인으로 전환하지 않고도 자유롭게 로그인할 수 있을까요?
예를 들어, 포럼 A, B, C가 있다고 가정해 보겠습니다. 포럼 A의 회원이 포럼 A의 자격 증명을 사용하여 포럼 B와 C에도 로그인하고 게시글을 작성할 수 있기를 원합니다. B와 C의 등록 회원도 동일한 방식으로 동작해야 합니다.
이 글과 그 이후의 글들은 여기서 논의된 기능의 하위 집합에 해당하므로 별도의 주제로 이동하는 것이 좋다고 생각합니다.
1개의 좋아요
Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso) - Integrations - Discourse Meta 링크가 도움이 될 수 있습니다 
1개의 좋아요
이론적으로는, ActivityPub 연동 프로토콜 서버로 기능하는 Discourse 플러그인을 만드는 것 외에 다른 가능성이 있을 수 있습니다. 바로 클라이언트 Social API 프로토콜을 준수하는 별도의 ActivityPub 서버에 계정을 설정하고, Discourse 플러그인이 ActivityPub 서버 역할을 하는 대신 해당 서버와 클라이언트 프로토콜을 통해 통신하는 방식입니다. 이 방식은 기존 ActivityPub 노드와의 보다 긴밀한 통합이라는 이점이 있을 수 있습니다. 하지만 서버 프로토콜을 구현하는 것보다 더 쉽지는 않을 것이며, 포럼 운영자에게는 연동 프로토콜 서버를 구축하는 것보다 훨씬 더 많은 수동 설정 작업이 필요할 것입니다.
사용자 상호작용의 가능성을 허용하기 위해 구현하려는 제 아이디어에서는, discourse-user-actors와 discourse-system-actors(예: 카테고리)를 구별하는 방법이 필요합니다. @#slug@discourse.example.org가 카테고리 액터가 되고, 나중에 @username@discourse.example.org 형식의 사용자 액터를 추가할 여지를 남기는 방식을 상상해 볼 수 있습니다. 하지만 해시태그의 보편성 때문에 실제로는 작동하지 않을 가능성이 높습니다.
4~5번 항목은 Discourse를 범용 ActivityPub 서버로 만들려는 시도에 가까워지고 있어, 이는 분명히 의도가 아니므로, 1~3번 항목에만 집중하는 것이 더 단순할 것입니다.
2개의 좋아요
Mastodon은 다음 정규식을 사용하여 유효성을 검사합니다:
USERNAME_RE = /[a-z0-9_]+([a-z0-9_\.-]+[a-z0-9_]+)?/i
MENTION_RE = /(?<=^|[^\/[:word:]])@((#{USERNAME_RE})(?:@[[:word:]\.\-]+[[:word:]]+)?)/i
제가 볼 때, 해당 USERNAME_RE는 원격 사용자에게 적용되는 것 같아, Discourse 사용자와 카테고리를 그렇게 별도의 네임스페이스로 구분하는 방법을 명확히 알 수 없습니다. 또한 이는 일반적인 하위 카테고리 슬러그를 배제합니다. @parentcategory:subcategory@discourse.example.org도 해당 정규식으로는 작동하지 않습니다.
선택적 서브도메인 @username@users.discourse.example.org이 가능할 수 있지만, 그렇게 하려면 SSL 및 DNS 설정이 더 많이 필요하고, 설정 오류가 많이 발생할 가능성이 높습니다. 아마도そこまで(그렇게까지) 가는 것은 가치가 없을 것 같습니다.
1개의 좋아요
다른 플랫폼과 연방을 형성하는 대신, Discourse 인스턴스 수가 매우 많으므로 모든 Discourse 인스턴스 사이에 연방을 형성하는 것이 더 합리적일 수 있습니다.
2개의 좋아요
여기에는 분명 막대한 잠재력이 있습니다. 가능성과 실현 가능성은 철저하고 신중한 검토를 요구합니다.
이것은 Xanadu의 영역일지도 모릅니다… (위 Jeff의 게시글을 읽고 그 안의 링크를 따라가 보세요.) 이러한 광범위한 통합은 대부분의 Discourse 인스턴스 관리자/운영자에게도 바람직하지 않을 가능성이 큽니다. (토론 포럼에서의 "트래픽 수준에 따른 설문"과는 달리) 관리자와 운영자를 대상으로 한 정식 조사가 필요합니다.
이는 연방된 사이트 중 하나만 해킹하여 사용자 자격 증명을 탈취할 수 있는 누구에게든 '왕국의 열쇠’를 내밀기 때문에 보안 해킹을 초래하는 초대장처럼 보입니다. 최소한 이러한 기능은 기본적으로 꺼져 있거나, 대부분의 보안 기능이 활성화되고 잠금 처리된 상태로 플러그인으로 명시적으로 로드되어야 합니다. Zoom은 플랫폼을 개방적이고 사용하기 쉽게 남겨 두어(사용자 확보와 육성을 위해) 빠르게 성장했지만, 악의적 사용자가 열린 현문을 발견하자마자 빠르게 보안 조치를 강화해야 했던 사례에서 이 교훈을 배웠습니다.
그럼에도 불구하고, 사이트들의 마이크로 연방(micro-federation)은 Discourse 구현에 도움이 될 것입니다. 만약 제 시를 위해 동일한 사용자 풀(예: 카운티/시 시민)을 통합하는 사이트의 원을 만들 수 있다면, 이는 사람들을 소통하게 하고 지역 거버넌스와 커뮤니티 생활에서 긍정적인 결과를 이끌어낼 수 있을 것입니다. 이 동일한 원리는 여러 Discourse 인스턴스를 관리하는 오버헤드를 정당화할 만큼 충분히 큰 모든 비즈니스에도 적용됩니다. 이렇게 하면 각 부서가 다른 부서로 쉽게 이동할 수 있는 자체 Discourse 컨테이너를 가질 수 있습니다. 그것이야말로 meta.discourse의 구현이라 할 수 있습니다.
하지만 Jeff, Sam, 그리고 동료들 [@codinghorror @sam] 및/또는 그들의 스티어링 위원회는 먼저 Discourse가 소셜 플랫폼인지 엔터프라이즈 플랫폼인지 결정해야 합니다. 제 선택은 엔터프라이즈입니다. 이 분리의 양쪽 모두에서 가장 큰 잠재력을 보고 있기 때문입니다. 엔터프라이즈는 비즈니스가 직원들을 지원할 수 있는 능력을 향상시킴으로써(비즈니스를 잘 돌보면 비즈니스도 당신을 잘 돌봐 줄 수 있습니다) 가장 큰 재정적 보상과 즉각적인 사회적 이점을 가져다줄 것입니다. 그 상업적 자금 중 일부는 아마도 social.discourse.org 재단을 지원할 수 있을 것입니다. 또한 엔터프라이즈에 유용한 기능들이 소셜 영역으로 잘 이식될 가능성이 매우 높습니다. 이 두 가지 요인은 전체적으로 윈윈(win-win) 상황을 만듭니다.
두 영역은 매우 다르므로 구별되어야 합니다. 그리고 ‘있으면 좋은’ 기능들은 필연적으로 주요 사용 사례인 버전을 우선시해야 합니다.
다행히도 이점은 양방향으로 흐릅니다. social.discourse.org에 관심이 있는 사람은 커뮤니티 구축의 사회적 측면과 커뮤니티 관련 활동을 수행할 수 있다는 점에서 보상을 받으므로, 이러한 비재정적 보상을 위해 일하고(자주 열심히 일하고) 있습니다. 이 social.discourse.org 작업은 필연적으로 엔터프라이즈 맥락에서 유용한 개발과 기능으로 이어져, Social Discourse Foundation의 비영리 지원을 대가로 Enterprise Discourse Incorporated에 가치를 돌려줍니다. 더 큰 윈윈입니다.
위에 쓰인 글에 느낌표가 하나도 없다는 점에 주목해 주세요. 이들은 단지 단순한 사실과 가능한 결과에 대한 진술일 뿐입니다. 매우 실용적입니다.
저는 몇 년 동안 제 비즈니스에 적합한 GroupWare 플랫폼을 찾아보고 있었습니다. Slack은 내부 비즈니스용으로 개발되었기 때문에(그리고 매우 흥미로운 기원 이야기가 있습니다) 잠시 큰 희망을 품게 했지만, 1차 스크리닝조차 통과하지 못했습니다. 저는 Discourse에 깊은 인상을 받았으며, Discourse에 대해 낙관적입니다.
1개의 좋아요
이것이 바로 이 주제의 핵심입니다. 즉, Discourse 인스턴스들 사이에서 말이죠.
OP(첫 번째 게시글)에도 명시되어 있습니다:
2개의 좋아요
맞아, 그리고
그리고
사이트의 마이크로 연방이 도움이 될 거야
모두 주제와 관련 있는 거지? 
반드시 선행 조건은 아닙니다. 플러그인 생태계도 고려해야 합니다.
상당히 큰 기능들은 종종 이러한 행정적 부담이나 중앙 집중식 계획이 필요하지 않은 플러그인이나, 가능한 경우 테마 컴포넌트로 개발됩니다.
이것이 바로 Discourse 생태계의 아름다움 중 하나입니다.
예를 들어 Pavilion은 Locations, Topic List Previews, Multilingual, Follow, Layouts, Custom Wizard(몇 가지만 언급한 것)를 CDCK와의 협의 없이 모두 개발했습니다. 그래서 저희가 이 논의에 관여하게 된 이유이기도 합니다.
7개의 좋아요
플러그인 개발자 여러분께 감사드립니다! 여러분은 개념 증명(PoC) 예제를 아낌없이 제공하며, 이를 현장에서 테스트하고 핵심 제품에 포함될 수 있도록 검토할 수 있게 해 줍니다. 여러분이 만든 다국어 플러그인은 그 훌륭한 예입니다!
python.org에서는 라이브러리 개발자들이 이 역할을 수행하며, 때로는 “반드시 필요해야 하는” 함수를 만들어 Python 핵심 패키지나 표준 배포 라이브러리에 포함되도록 수용받기도 합니다.
2개의 좋아요
저는 이 포럼의 여러 주제, 예를 들어 여기에서 Discourse에 연동(federation) 지원을 추가할 것을 꾸준히 주장해 왔습니다. 현재 Fediverse가 주류로 부상하고 있으며, Tumblr와 아마도 Flickr 등이 연동 지원을 추가하면서, Discourse도 이 기능을 추가할 의사가 더 있는지 궁금해집니다.
Flarum의 핵심 개발자로부터 AP(ActivityPub) 구현에 대한 조언을 구하는 연락을 받았고, 제가 언급한 링크를 포함한 몇 가지 자료를 공유해 주었습니다.
P.S. Fediverse 개발자 커뮤니티인 SocialHub의 Discourse 포럼에서, 우리는 상당한 기간 동안 독립적인 포럼들이 대부분의 사람들이 참여하는 데 너무 큰 장벽이 되고 있음을 인식하며, 어떻게 하면 Fediverse의 일원이 될 수 있을지 모색해 왔습니다.
7개의 좋아요
요즘 저는 Mastodon에 약간 관심을 갖게 되었습니다(도메인 이름을 구매할 정도이지만, 실제로는 설치하지는 않았습니다). 그래서 Discourse를 Mastodon과 인증하는 방법에 대해 조금 읽어 보았습니다.
사람들이 생각했던 것보다 더 어렵다는 몇 가지 게시물을 발견했습니다. 기억이 맞다면, 플러그인 개발을 위한 기금이 제안되었지만 결국 무산된 것으로 보였습니다. 제 추측이지만, 이것은 10,000달러 규모의 문제일 것입니다. 제 추측이 맞다면, 바로 그런 종류의 주장(advocacy)이 필요할 것입니다.
수정: 하지만 저는 인증(authentication)과 연동(federation)을 혼동하고 있었습니다.
1개의 좋아요
여기서 제가 일반적인 우려를 하는 이유는, 아이디어들이 대체로 너무 거대해서 작은 단위로 나누기가 매우 어렵기 때문입니다.
연동(federation)이라는 아이디어는 흥미롭다고 생각합니다. 구체적인 구현 방식은 다음과 같이 제안할 수 있습니다:
- Discourse 관리자가 특정 카테고리를 연동할 수 있도록 허용합니다.
- 마스토돈(Mastodon) 사용자는 해당 카테고리를 팔로우할 수 있습니다. 예:
announcements@meta.discourse.org - 새로운 공지사항 토픽이 생성되면, 발췌문과 원본 링크를 포함해 새 게시물이 연동됩니다.
- 사용자가 Discourse에서 응답하면, 새 댓글이 연동되며 원본 토픽에 대한 답변으로 표시됩니다.
- 페디버스(Fediverse)에서 누군가 댓글을 달면, 마스토돈의 게시자로 표시된 ‘섀도우’ 게시물이 해당 토픽에 생성됩니다.
이 정도 규모라면 제 머릿속에 제대로 들어갈 만큼 충분히 작습니다.
13개의 좋아요
ActivityPub의 문제는 읽기 쉬운 공개 표준이라는 점에도 불구하고, 이를 구현한다고 해서 바로 "페디버스(Fediverse)의 일부"가 되는 것은 아니라는 것입니다. 구현해야 할 다른 요소들이 많이 있으며, 특히 토론 포럼 도메인의 경우 메시지 교환을 위한 사용자 정의 ActivityPub 어휘가 필요합니다. '부트스트랩’할 수 있는 다른 프로젝트나 채택할 수 있는 라이브러리가 있지만, 상당한 개발 작업이 필요할 것입니다.
애드보커시(주장) 측면에서는… 개인적으로 잘 구현된 AP(ActivitPub) 지원이 제품에는 USP(독점적 판매 주장)를 추가할 수 있다고 생각합니다. 모든 포럼에 가입할 필요가 없다는 점은 하나의 장점입니다. 저에게도 이는 장벽이니까요. 이 한 게시물만 추가하려고 또 다른 Discourse에 가입해야 할까요?
하지만 연동(federation)은 훨씬 더 큰 가치를 가져올 수 있습니다. 제 이상적인 시나리오로는 개인용 Discourse를 설치하거나 인스턴스에 가입한 후, Mastodon처럼 처음에는 완전히 비어 있는 상태에서 시작하는 것입니다. 그런 다음 내 필요와 관심사에 따라 커뮤니티 구조를 직접 채워 넣습니다. 이 테마의 그룹을 선택하고 이 카테고리 아래에 추가하며, 또 다른 그룹을 추가하는 식입니다.
업데이트: @sam과 크로스포스팅했습니다 .. 이는 @pfaffman에 대한 반응이었습니다.
5개의 좋아요
네, 좋은 시작이 될 것 같습니다. Lemmy 링크 어그리게이터(Lemmy link aggregator)는 커뮤니티의 연방(federation)을 제공하는 방식으로 작동하며, 그와 유사한 구조를 갖추고 있습니다. 참고로 더 광범위한 상호작용은 매우 유용할 것이지만, 초기에는 연방이 Discourse 인스턴스/테넌트 사이에 구현될 수 있습니다.
모든 것이 Mastodon에 맞지는 않습니다. Mastodon은 마이크로블로깅 앱이며 마크다운을 지원하지 않습니다(다른 페디 앱들은 이를 지원합니다).
현재 추가적인 연방 Groups 지원 작업이 진행 중입니다. Lemmy가 그 예시입니다. Bonfire는 Google+와 유사한 서클(circles) 등을 추가할 예정입니다.
3개의 좋아요
좋아요! 바로 제가 보고 싶었던 워크플로우입니다. 그리고 널리 알리고 싶습니다. 
발췌문의 길이를 편리하게 설정할 수 있도록 하면 좋겠습니다. 0은 발췌문이 아닌 전체 기사를 의미하는 것이죠. 참고로 Mastodon의 500자 제한은 임의적인 것이며, Fediverse, ActivityPub, ActivityStream과는 아무런 관련이 없습니다. 제가 현재 운영하는 Mastodon 노드들은 2000자 제한을 적용하고 있으며, social.kernel.org의 제한은 31337자입니다. 글쓰기 시 500자 제한을 가진 기본 Mastodon조차도 더 긴 게시물을 표시하는 데에는 아무 문제가 없습니다.
제가 보는 사소한 어려움은 Discourse에서 사용자(user)와 카테고리(category) 네임스페이스가 서로 분리되어 있지만, ActivityPub에서는 동일한 "Actor"로 취급된다는 점입니다. 그리고 적어도 Mastodon은 Actor를 인식하는 데 상당히 제한적인 정규식(regexp)을 사용합니다. #announcements 카테고리의 경우 @announcements@meta.discourse.org를 사용한다고 가정하면, 이 댓글은 @mcdanlj@meta.discourse.org가 작성한 것으로 연동(federate)될 것입니다.
기본적으로 Discourse 관리자로써 저는 Actor 이름으로 카테고리 슬러그(slug)를 사용하길 원합니다. 관리자가 카테고리에 대해 연동을 설정할 때 Actor 이름을 선택하게 하고, 이것이 기본적으로 슬러그로 설정되며, (그룹 이름처럼) Discourse 사용자 이름에 대해 고유하도록 하면 될 것 같습니다.
(참고로, 저는 예전에 Actor 이름 인식을 위한 Mastodon 정규식에 대해 우려한 적이 있지만, 실제로는 @멘션으로 사람을 지목할 때만 사용되는 것으로 생각됩니다. 여기서는 그 가치가 없으므로, 예를 들어 #documentation:admins를 @documentation:admins@meta.discourse.org로 표현하는 것이 실제로 작동할 수도 있습니다. 하지만 Mastodon과 Pleroma를 반드시 포함하여 주요 마이크로블로깅 시스템 여러 개로 확실히 테스트해 보고 싶습니다.)
3개의 좋아요
예를 들어 Mastodon이나 Pleroma 사용자의 관점에서 이것이 실제로 어떻게 보일지 생각해보면, @announcements@meta.discourse.org가 @sam@meta.discourse.org의 주제 게시물을 부스트/재블로그하고, @mcdanlj@meta.discourse.org의 댓글 게시물을 OP(원본 게시물)에 대한 댓글로 부스트/재블로그하는 형태가 될 것입니다. 주제 게시물도 댓글도 실제로는 카테고리가 작성한 것이 아니라, 특정 카테고리의 사람이 작성한 것입니다.
플러그인이 초기에는 카테고리 액터(Actor)에 대해서만 웹핑거(WebFinger)를 구현할 수 있지만(이를 통해 팔로우할 수 있도록 하기 위해), 궁극적으로 개별 사용자에 대해서도 구현하는 것이 합리적일 수 있습니다. 저는 Mastodon에서 @sam@meta.discourse.org를 팔로우하여 그의 게시물과 댓글을 보고 싶을 수 있습니다.
2개의 좋아요
질문: 이 논의의 현재 상태와 가능한 구현 계획은 어떻게 되나요? 예를 들어 테스트 지원이 필요합니까? 아니면 그 질문이 "너무 이르다"고 보시는 건가요? 