커뮤니티는 경계가 없다: Discourse-as-a-Fabric - 아이디어 및 브레인스토밍

ActivityPub 지원: Phase 1 RFC에서 저는 Discourse에 ActivityPub 지원을 도입할 비즈니스 사례를 평가하고, Discourse가 처음부터 연동(federation)을 염두에 두고 구축되었다고 가정하여 MVP를 넘어선 가능성을 살펴보기 위한 아이디어 발상 운동을 제시했습니다:

따라서 저는 현재 코드베이스의 기술적 실용성을 고려하지 않고, 네이티브 연동 지원이 어떤 모습일지에 대한 비전을 가지고 브레인스토밍으로 아이디어 발상을 시작하겠습니다. 이 모든 것에는 많은 세부 사항과 엣지 케이스가 있다는 것을 인지하고 있습니다. 자, 시작합니다..

커뮤니티에는 경계가 없다

(Pixabay의 Pexels 사진)

우리는 모두 하나의 행성을 공유하며 복잡한 사회 구조 속에서 섞여 살아갑니다. 왜 Discourse 커뮤니티가 단일 포럼으로 제한되어야 하는가요?

저는 Humane Tech Community (HTC)의 관리자이며, 우리는 기술 관련 다양한 주제 영역을 다루고 있으며 “자유 > 프라이버시”, “정렬 > 윤리”, “정렬 > 표준” 등의 (하위)카테고리를 가지고 있습니다. 아마도 너무 광범위할 수 있으며, 이러한 카테고리에 특화되어 우리를보다 더 잘 수행하는 다른 많은 Discourse 포럼들이 존재합니다. 그러나 휴먼 테크놀로지라는 _전체 분야_에 대한 개요를 얻고자 하는 사람들에게는 이러한 광범위한 포지셔닝이 합리적입니다.

카테고리 연동

예를 들어, 우리의 “프라이버시” 하위 카테고리를 PrivacyTools 포럼의 “블로그 게시물” 하위 카테고리와의 연동이 가능하다고 가정해 봅시다. 아마도 HTC의 프라이버시 하위 카테고리가 더 광범위한 범위를 가지고 있으므로 한 방향으로만 주제를 동기화하도록 설정할 수 있습니다 - PrivacyTools에서 생성된 주제가 HTC 포럼에 나타나고, 우리의 멤버들이 그와 상호작용할 수 있도록 하는 것입니다. HTC 포럼의 주제 게시물은 PrivacyTools의 해당 주제로 다시 전송되고 그 반대도 마찬가지입니다. 두 포럼의 주제는 동기화 상태로 유지됩니다. 아마도 저는 PrivacyTools의 여러 하위 카테고리를 HTC의 "프라이버시"로 한 방향으로 동기화하는 것도 원할 수 있습니다. 그리고 왜 비슷한 방식으로 다른 프라이버시 관련 커뮤니티들과 동기화하지 않겠습니까.

또 다른 예입니다. Feneas와 SocialHub 모두 최상위 “ActivityPub” 카테고리를 공유합니다. 여기에는 중복이 있으며, 한 커뮤니티의 멤버들이 다른 커뮤니티에서 무슨 일이 일어나고 있는지 모르고 있습니다. 이는 "ActivityPub"이 양방향 동기화의 후보가 될 수 있는 기회로, 각 포럼이 동일한 주제 목록을 포함하게 됩니다.

태그 및 개별 주제 연동

태그에도 동일한 원리가 적용될 수 있으며, 특정 태그가 연동되도록 구성될 수 있습니다. 예를 들어, SocialHub에서 #specification 태그가 있는 모든 주제가 HTC의 “정렬 > 표준” 하위 카테고리로 연동되도록 설정할 수 있습니다.

주제는 또한 툴바 명령을 통해 트리거되는 경우별(case-by-case)로 연동될 수 있으며, 이때 연동할 대상 포럼을 지정하고, 주제가 나타날 원격 카테고리를 선택할 수도 있습니다(즉, 원격 브라우징을 위해 포럼 카테고리 목록도 연동됨).

멤버 멘션 및 프로필 보기

주제가 다른 포럼으로 연동되면, 내부의 멘션은 멤버가 어디에 위치하는지 반영하도록 조정되어야 합니다. HTC에서의 제 @aschrijver 핸들은 동기화 후 SocialHub 포럼에서 @aschrijver@humanetech로 나타날 수 있습니다.

저는 SocialHub에서도 사용자이므로, 프로필 설정에서 계정을 연결할 수 있으며, 인증 후 동기화된 주제에서 제 로컬 계정 핸들이 표시될 수 있습니다.

원격 핸들 또는 멤버 아바타를 클릭하면 원격 포럼의 프로필 카드가 표시됩니다. 프로필 요약을 보기 위해 다시 클릭하면, 동기화된 주제 상호작용으로 인해 로컬 포럼에서 발생한 활동 지표만 표시될 수 있습니다. 또는 더 흥미롭게도, 연동 설정의 일부인 모든 알려진 포럼의 요약을 표시할 수 있습니다. 예를 들어, 저는 응답이 다른 포럼의 매우 활동적인 전문가 멤버로부터 온 것임을 알 수 있게 될 것입니다.

직접 메시지 및 알림

DM은 로컬이 아닌 모든 연동 포럼 간에 가능하며, DM에서 원격 멤버를 태그/멘션함으로써 가능합니다. 그 외에는 DM 통신 방식에 차이가 없습니다. 현재 로컬 전용 DM과 동일하게 작동합니다.

위에서 설명한 모든 연동 사항으로부터 알림도 연동할 필요가 생깁니다. 원격 멤버의 게시물에 응답하거나, 그 게시물을 좋아하거나, 동기화된 주제 스레드에서 그들을 멘션하면, 원격 포럼에 멤버를 알리기 위한 UI 알림이 나타날 수 있습니다. 이메일 알림도 원격 포럼에서 처리됩니다. 그러나 멤버가 두 포럼 모두에서 계정을 연결했다면, 상호작용이 처음 발생한 로컬 포럼에서 알림이 올 수 있습니다.

단일 로그인 (SSO)

지금까지 설명된 모든 기능에서 SSO가 필요하지 않다는 점에 유의하세요. 원격 멤버는 다른 연동 포럼에 자동 특권 접근 권한을 갖지 않습니다. 그렇다면 일방향 동기화된 주제 스레드에서 멘션되면 어떻게 될까요? 그 경우, 그들은 자신의 포럼 인스턴스에서 온 UI 알림과 이메일을 받게 되며, 클릭하면 다른 포럼(아마도 새 브라우저 탭에서)으로 이동하여 주제를 단순히 볼 수 있습니다. 응답하려면 먼저 가입하고 계정을 연결해야 합니다.

Fediverse에서 SSO는 아직 좋은 해결책이 없는 까다로운 문제라는 점에 유의하세요. 그러나 Discourse-to-Discourse 연동에서는 SSO 기능을 구현하는 것이 훨씬 쉬울 수 있습니다. SSO 통합이 있다면, 알림을 클릭하면 현재 포럼 내에서 컨텍스트에 맞게 주제가 열릴 수 있으며('원격 보기’로), 멤버가 원활하게 상호작용할 수 있습니다.

연동 관리 및 복잡성

이 전체 사용 사례는 Discourse가 처음부터 내장된 연동 지원과 함께 구축되었다고 가정하여 설명되었습니다. 이 모든 것이 구현되면 제품의 거의 모든 기능에 영향을 미칩니다. 이 스레드를 시작한 사용 사례인 FB 스타일 개인화된 피드와 달리, 여기의 연동은 개별 멤버의 임의적인 판단이 아니라 포럼 스태프에 의해 신중하게 관리됩니다.

연동 설정의 대부분은 관리자 전용 사항입니다. 커뮤니티 조직과 콘텐츠가 직관적이고 논리적으로 유지되도록 전략적이고 좋은 계획에 따라 수행되어야 합니다. 연동 설정은 캐주얼하게 추가되는 것이 아니라, 커뮤니티 빌딩 워크플로우의 일부로 시간이 지남에 따라 점진적으로 구축됩니다.

상호 운용성

물론 이 ActivityPub 지원 비전은 Discourse로 제한될 필요가 없습니다. 모든 호환 가능한 소프트웨어 프로젝트가 분산 커뮤니티 구조의 일부가 될 수 있습니다. 예를 들어, 제가 방금 이 게시물의 방향을 가리켜 준 forem의 오픈소스 커뮤니티 빌딩 소프트웨어와 loomio 협업 의사결정 플랫폼 등이 있습니다. 그러나 Discourse는 이 모든 것에서 선두를 차지할 기회를 가지고 있습니다.

Fediverse 통합

지금까지의 모든 연동 지원은 포럼/커뮤니티 비즈니스 도메인으로 제한되었지만, ActivityPub 통합을 통해 상호 운용성은 더 넓은 Fediverse를 포괄하여 확장될 수 있으며, 수많은 흥미로운 비즈니스 사례를 가능하게 합니다. 지금 제 머릿속에 떠오르는 몇 가지를 나열해 보겠습니다:

  • Mastodon / Pleroma 마이크로블로깅 플랫폼의 투츠(toots)로 포럼 게시물을 Fediverse 전체에 공지합니다.
  • 임베드된 이미지는 자동으로 PixelFed에 업로드되고 거기서 제공됩니다(예: Blender 커뮤니티에 적합).
  • 날짜/시간 툴바를 사용하여 Fediverse를 대상으로 한 전체 Mobilizon 이벤트를 RSVP 기능과 함께 설정합니다.
    • 통합은 양방향으로 활성화되며, 이벤트의 Mobilizon 토론은 실제로 Discourse 주제입니다.
  • 특별한 비디오 기능을 가진 PeerTube 주제를 생성하며, 게시물은 PeerTube의 댓글 스레드입니다.
    • Owncast도 AP 지원을 추가하면 마찬가지입니다(이 이슈 참조).
  • 게시된 주제가 자동으로 Writefreely 블로그 게시물 및 댓글 스레드가 됩니다.
  • 포럼의 일부를 Nextcloud에 앱으로 임베드합니다(그들의 ActivityPub 지원을 통해).
  • 팟캐스트 기능을 Funkwhale을 통해 통합합니다(팟캐스트 지원에 대한 최근 비디오 참조).
  • 개발 중인 전문 소셜 네트워크(LinkedIn 같은 롤로덱)인 Flockingbird에서 프로필 정보를 가져옵니다.

ActivityPub Watchlist의 계속 증가하는 앱 수를 살펴보고 상상력을 펼쳐 보세요 :smiley:

결과

잠시 모든 기술적 장벽과 장애물을 잊고, 이것이 Discourse라는 제품에게 무엇을 의미하는지 생각해 봅시다. 또는 Discourse가 더 이상 '단순한 제품’이 아닌 경우: Discourse는 분산 커뮤니티 구조가 되었습니다.

포럼 스태프는 더 이상 단순히 스태프가 아닙니다. 그들은 커뮤니티 빌딩에 훨씬 더 넓은 관점을 채택하게 될 것입니다. 커뮤니티와 커뮤니티 콘텐츠는 모두 Discourse 구조 전체에 걸쳐 존재합니다. 스태프는 다른 Discourse 인스턴스를 적극적으로 살펴보고, 그들의 스태프를 접촉하여 파트너십을 형성하고, 커뮤니티 조직과 콘텐츠를 가장 흥미롭게 슬라이스하고 다듬기 위한 흥미로운 연동 설계를 만들 것입니다.

커뮤니티 멤버들도 훨씬 더 잘 서비스받을 것입니다. 더 흥미로운 콘텐츠가 그들의 포럼 '포털’로 흘러들고, 포럼은 로컬에만 국한된 것보다 더 활동적이 될 것입니다. 커뮤니티 멤버들은 구조 전체에 걸쳐 다른 포럼 인스턴스의 멤버들을 발견하고 상호작용할 수 있게 됩니다. 사실 커뮤니티 경계는 제거되었습니다: 커뮤니티에는 경계가 없다.

17개의 좋아요

공평하게 말하자면, 나는 가볍게 훑어보기만 했지만: 이 fabric 아이디어로 해결하려는 문제는 무엇입니까?

2개의 좋아요

우선, 브레인스토밍의 입력 자료로 제한 없이 다양한 가능성을 제시해 보았습니다. 하지만 개인적으로는 두 가지 문제에 대한 개선을 보고 싶으며, 하나는 일반 커뮤니티 멤버로서, 다른 하나는 커뮤니티 촉진자(현재 5개 포럼에서 스태프로 활동하며 가끔 크로스포스팅을 하는 역할)로서입니다:

  • 커뮤니티 멤버로서 저는 현재 15~20개의 Discourse 포럼에 계정을 보유하고 있습니다. 계정(일부는 잊어버린 것 포함)과 비밀번호를 관리해야 하고, 인기 있는 포럼들을 캐러셀처럼 하나씩 돌아가며 확인해야 합니다. 제 관심사 때문에 이 포럼들의 콘텐츠 영역이 상당 부분 겹칩니다. 만약 제가 좋아하는 주제에 대한 훌륭한 포럼에 가입하라고 권유하신다면, 또 다른 계정을 만들어야 한다는 이유로 여전히 매우 망설여질 것입니다.

  • 커뮤니티 촉진자로서 저는 이와 유사하고 관련 있는 문제를 겪고 있습니다. 제 커뮤니티는 작을 수 있고, 당신은 유사하거나 부분적으로 겹치는 주제의 콘텐츠를 다루는 다른 커뮤니티에 가입하는 것을 선택할 수도 있습니다. 혹은 그 반대일 수도 있고요. 또는 아예 그 다른 훌륭한 커뮤니티의 존재를 알지 못할 수도 있습니다(아마도 저는 커뮤니티 촉진자로서 그 존재를 알지만, 제 멤버들에게 알리기 위해 고정 게시글을 작성할까요?).

페더레이션 지원이 구현된다면, 커뮤니티 촉진자들은 파트너십을 통해 협력하고, 연속적인 청중을 위한 포럼 조직을 설계하며, 서로의 강점에서 이익을 얻는 상생의 결과를 얻을 수 있을 것입니다. 구체적으로 이는 다음을 포함합니다:

  • 페더레이션할 가장 적절한 소스를 선택하여 더 높은 품질의 콘텐츠를 제공할 수 있는 능력.
  • 페더레이션의 합산 결과로 더 큰 회원 기반을 확보하여, 흥미로운 담론을 나눌 수 있는 사람이 많아짐.
  • 페더레이션에 참여하는 모든 포럼 인스턴스의 활동 수준이 높아져, 재방문객 유지에 도움이 됨.

성공적인 커뮤니티에 필수적인 세 가지 측면, 즉 품질, 양, 그리고 활동성입니다 :slight_smile:

8개의 좋아요

동의합니다. 이 문제는 정말 번거로울 수 있습니다. 저는 이 문제를 Discourse 커뮤니티의 RSS 피드를 추가하고, 내장된 주간 다이제스트 이메일을 활성화하여 해결합니다.

5개의 좋아요

최근 니얼 퍼거슨의 『The Square and the Tower』를 막 읽었습니다. 이 책은 세계사 전반에 걸쳐 개인 간에 존재하는 모호하고 비공식적인 사회적 연결, 즉 사회 네트워크의 영향을 다룹니다. 이 책은 완벽하지는 않지만, "커뮤니티에는 경계가 없다"는 당신의 주장을 일관되게 뒷받침합니다. 분산 네트워크는 위계 구조보다 회복력이 뛰어나고, 혁신적이며, 평등합니다. 디스코스는 자신을 "전면 재구축, 오늘날 보편화된 스마트폰, 태블릿, 페이스북, 트위터가 존재하는 세계에서 현대적인 인터넷 토론 포럼이 어떠해야 하는지를 재설계하려는 시도"라고 설명합니다. 디스코스의 목표가 단순히 시대의 최신 최고급 포럼 소프트웨어가 되는 것이 아니라면, ActivityPub 연동은 페이스북, 구글, 트위터 등을 진지하게 도전하고 온라인 커뮤니티가 될 수 있는 가능성에 대한 기대를 뒤집는 명확한 길입니다.

8개의 좋아요

@aschrijver 물론이죠, 저는 개인적으로 이 아이디어와 사고방식을 정말 좋아합니다.

이것은 꽤 “쉽게” 실현 가능해 보입니다. 계정 부분은 메인 Discourse를 SSO 제공자로 활용하는 방식을 사용할 수 있습니다. 다른 Discourse 포럼들은 중앙 사용자 기반을 구축하기 위해 이 시스템에 참여하기만 하면 됩니다: 사용자 이름은 해당 Discourse를 사용하는 모든 곳에서 해당 사용자에게 예약됩니다. 이상적으로는 포럼 관리자/소유자가 포럼 생성 시점에 참여해야 합니다. 나중에 참여하는 것도 가능하지만, 그때 나타나는 중복 사용자 이름 문제를 해결해야 합니다: 시스템에서 이미 사용 중인 사용자 이름인 경우, 관리자가 사용자에게 사용자 이름 변경을 요청해야 합니다.

파트너십 부분은 Matterbridge와/또는 Discourse API를 사용하는 플러그인이 모든 작업을 수행할 수 있어야 합니다. 여기서는 일부 플러그인 개발과 정교화가 필요합니다.

대안적으로, 새로운 포럼의 경우 “멀티사이트” 접근 방식에 대한 해결책이 있을 수 있습니다: 하나의 메인 Discourse(위 아이디어의 SSO 제공자와 동일할 수 있음)에 카테고리를 생성하고, 하나의 카테고리 = 하나의 "포럼"으로 설정하는 것입니다. 몇 가지 설정을 조정하면 소수의 사용자를 해당 카테고리에 “잠금” 처리하고, 메인 "카테고리"에 대한 언급을 제거하여 이를 서로 다른 "포럼"으로 재정의할 수 있습니다. 하위-하위 카테고리를 활성화하면 각 포럼은 여전히 2단계의 카테고리를 갖게 됩니다. 조정해야 할 부분이 있지만, 이를 통해 직접적인 공용 사용자 기반과 개인 메시지 교환(같은 Discourse에 있으므로!)이 가능해집니다.

두 가지 접근 방식을 결합할 수 있습니다: 메인 Discourse에 호스팅된 포럼과 외부에서 링크되는 포럼을 함께 사용하는 것입니다. 저는 이 비전을 현실로 구현하는 것이 꽤 쉽게 가능하다고 생각합니다. 관심이 있다면 이 작업에 참여할 의향이 있습니다(다만, 도움이 필요할 것입니다). 이 목적에 사용할 수 있는 도메인 webforum.link를 등록해 두었습니다.

참고(이전 게시글을 확인한 후): ActivityPub는 "개방형"입니다. 위 아이디어들은 훨씬 더 "폐쇄적"이며 Discourse 포럼에 제한됩니다. 참여하기도 더 쉽지 않을 것입니다.

3개의 좋아요

@aschrijver, ActivityPub Support: Phase 1 RFC - #50 by Mevo 에서의 게시글 교환을 이어가며, 또한 이곳(이곳이 더 적합한 주제입니다)에서 이야기를 나누고자 합니다:

최근 꽤 흥미롭게 느낀 점이 하나 있습니다. 몇몇 사람들이 무료이고 분산된 마켓플레이스인 Openbazaar를 만들었습니다. 그 아이디어는 기본적으로 완전히 개방되어 있고, 누구나 제한이나 검열의 가능성 없이 어떤 물건이든 판매할 수 있는 공간을 만드는 것이었습니다. 결제는 암호화폐를 기반으로 하며, 판매자를 리뷰할 수 있는 기능과 거래에 문제가 발생할 경우 중재할 수 있는 모더레이터 시스템이 존재합니다. 거래 수수료는 전혀 없으며, 이 서비스는 100% 무료입니다(모더레이터의 개입이 필요한 경우 소액의 수수료가 발생할 수 있습니다).

개인적으로, 이론상으로는 이 시스템이 훌륭하다고 생각합니다. 그러나 실제로는 크게 성공하지 못했습니다. 반면, 모든 거래에서 상당한 수수료를 받는 eBay나 Amazon은 매우 잘 운영되고 있습니다.

핵심은, 무언가를 통제하고, 그로부터 재정적 이익을 얻기 때문에 잘 작동하도록 만들 동기가 있으며, 이를 위해 투자하는 사람이 있을 때, 무료이고 개방적이며 고귀한 아이디어들보다 더 잘 작동하는 경우가 많다는 것입니다. 매우 슬픈 일이지만, 현실에서는 실제로 이런 일이 일어나는 것 같습니다.

Mastodon은 Facebook과 Twitter를 대체했습니까? 그럴 수 있을까요? 사용자들이 Facebook에서 쏟아지는 광고량에 지쳐 있는 것 같지는 않습니다.

어쨌든, 연동(federation)에 대한 당신의 관점에서 이 측면을 고려하지 않은 것으로 보입니다. 따라서 이 점을 고려해 보시거나(최소한은 인지해 두시거나) 참고하시라고 말씀드립니다. 연동 옵션을 제공하거나 파트너십을 맺는 것이 좋은 아이디어가 아니라는 의미는 아닙니다. 하지만 '완전한 연동(full federation)'으로 가면, 소프트웨어를 운영하는 매력이 줄어들 수 있습니다. 그러면 소프트웨어는 단순히 '노드’가 되어 더 이상 사용자가 통제할 수 있는 것이 아니게 되니까요. 적어도 그 부분은 꽤 다른 문제입니다.

1개의 좋아요

플랫폼 사용의 진행은 선형적이지 않습니다. Signal을 예로 들어 보겠습니다. 스노든이 "Silent 또는 Signal을 사용하라"고 말했고, 해당 앱은 발전했습니다. 그러나 그것은 여전히 니치(niche) 수준에 머물러 있었습니다. 가파(GAFAM)가 불통(불통적인 의사소통)을 일삼고, 엘론 머스크가 "Signal을 사용하라"라고 말했을 때, 수백만 명의 사용자가 동일한 기준을 동시에 벤치마킹하고, 도착한 앱이 그들의 요구에 부응했기 때문에 몰려들었습니다.

일부 사용자는 피드에서 반응을 제공하는 주요 제공자의 계정이 삭제된 것을 보고, 미디어의 큰 보도 없이도 최근 트위터와 페이스북을 떠났을 수 있습니다.

소셜 미디어 시스템이 càng 혼란스러워질수록, 사용자가 "앱1을 삭제하고 앱2를 설치한다"는 행동을 동시에 대규모로 수행할 확률은 높아집니다.

1개의 좋아요

Signal 예시는 정말로 비교할 수 없다고 생각합니다. 여기서는 명확한 추가 기능이 있고, 사람들이 그것을 사용해야 하는 이유(WHY)가 있습니다: “암호화된 통신을 사용하여 말한 내용이 사적으로 유지되고 아무도 이를 엿들을 수 없도록 하세요.” 이는 암호화되지 않은 상태에서 암호화된 상태로 넘어가는 것입니다.

하지만 "폐쇄적"이고 “격리된” 플랫폼에서 “개방형” 플랫폼으로 넘어갈 때, "완전한 연방제(full federation)"를 생각해보면, 사용자에게 정말로 무언가를 가져다주는 것일까요? 사용자 입장에서 정말로 기능이 추가되는 것일까요? 일부는 네라고 말할 수 있습니다. 여러 커뮤니티에 참여하는 모습을 보고, 이를 통합할 수 있다고 생각하기 때문입니다(여러 개의 서로 다른 커뮤니티에 로그인하는 것이 얼마나 부담스러운지 이해합니다). 하지만 동시에, 모든 사용자가 하나의 지배적인 “폐쇄적” 커뮤니티로 이동한다면, 그들에게는 거의 같은 것이 될 것입니다. 차이가 보이거나 "개방성"을 원할지 확실하지 않습니다.

사람들은 콘텐츠, 상호작용 등에 관심을 갖지만, 기술적으로 어떻게 작동하는지 또는 누가 그것을 통제하는지에 대해 그들에게 중요할까요? "연방제"로의 전환은 커뮤니티의 관점에서 보면 경쟁에서 공유로 넘어가는 것입니다. 서로 친구일 수 있고, 사용자를 한 곳에서 다른 곳으로 보내는 것에 문제가 없을 수 있지만, 폐쇄적인 상태에서는 여전히 경쟁합니다.

두 번째 점이 흥미롭습니다: 어떤 "연방제"가 계정 차단, 계정 삭제, 검열을 방지할 수 있을까요? 이것이 사람들에게 추가되는 "기능"이 될 수 있습니다. 현재 ActivityPub에서는 개별 사이트에서 차단당할 수 있지만, 등록한 사이트가 당신을 차단하지 않는 한 연방제 나머지 부분에 계속 게시할 수 있다고 생각합니다. @aschrijver , 그 메커니즘이 어떻게 작동하는지 아시나요? (ActivityPub에 대해 충분히 잘 알지 못합니다). 연방제 수준에서 등록하는 건가요, 아니면 연방제에 속한 사이트 중 하나에 등록하는 건가요? 연방제 수준에서 차단당할 수 있나요? 아니면 불가능한 건가요? (불가능해야 하는 것 아닌가요?)

@jibe-b 질문은 app1에서 app2로 넘어가는 것이 아니라, 개별 폐쇄형 앱과 연방제(개방형) 무언가를 비교하는 것이었습니다. 강력한 표현의 자유 정책과 사용자 차단을 하지 않는 폐쇄형 개별 앱도 있을 수 있습니다(사후적으로 말하기는 쉽지만, "반응 제공자(provider of reactions)"는 이런 상황을 예상할 수 있었습니다). 완전히 탈중앙화하고 누구에게도 차단 기능을 제거함으로써 차단 없는 환경을 보장할 수 있습니다. @aschrijver 의 초기 목표가 검열 방지는 아니었다고 생각합니다.

1개의 좋아요

(간결성을 위해 발췌했습니다). 여기서는 레스토랑 비유가 약간 무리가 있습니다. 마치 두 개의 테이블에 동시에 앉아 있고, 더 많은 사람들과 축하할 수 있는 더 큰 ‘통합된’ 레스토랑에 있는 것과 같습니다. 당신이 말하는 것은 사실일 수 있지만, 또한 구현 방식에 따라 완전히 달라질 수도 있습니다.

ActivityPub RFC 주제와 @hellekin의 사용 사례가 개인에게 완전한 통제권을 부여하는 반면, 위에서 설명한 제 시나리오에서는 커뮤니티 구조를 완전히 커뮤니티 스태프의 손에 맡깁니다. 그들은 다른 커뮤니티와 파트너십을 맺고, 상호 동의에 기반하여 커뮤니티의 일부 단면만 공유할 수 있을 것입니다.

이것이 Discourse(회사)의 이익과, 자신의 정체성과 회원 기반을 구축하는 데 많은 노력을 기울이는 커뮤니티 매니저들의 이익에 더 부합할 것이라고 생각했습니다. 즉, 더 _비즈니스 사례_에 가깝습니다. 따라서 스태프는 여전히 완전한 통제권을 가지며, 구성 커뮤니티 조직이 포괄적이고 직관적이도록 유지하는 책임도 집니다. 그들은 "커뮤니티 조직의 편집자"입니다.

Discourse 사용자에게 어디서든 포럼 콘텐츠를 가져와 빈 '포털’을 채울 수 있는 완전한 자유를 허용한다면, 완전히 다른 커뮤니티 역동성이 생길 것입니다. 이 사용 사례는 특정 경우에 가치를 지니지만, '스태프가 통제’하는 사용 사례와는 완전히 다른 것입니다. 물론, 그 사이의 모든 회색 지대도 가능합니다.

네, 알고 있으며 OpenBazaar의 탈중앙화 마켓플레이스라는 _아이디어_를 좋아하지만, 암호화폐가 저를 주저하게 만든 요인이었습니다. 이는 신뢰의 문제입니다. 많은 사람들에게도 이것이 발목을 잡았을 수 있습니다. 하지만 그 외에도, 기존 빅테크의 거대한 네트워크 효과 때문에 신규 진입자가 진입하기가 매우 어렵습니다. 그들은 새로운 서비스를 출시하고, 일일 방문자가 수백만 명인 사이트에서 광고하며, 마침내 서비스가 성공할 때까지 큰 적자를 감수하고 운영할 수 있기 때문입니다.

네, 동의합니다. 그것이 제가 위에서 설명한 "완전한 자유"보다는 “스태프 통제” 사용 사례에 초점을 맞춘 이유입니다. ActivityPub 지원이 유료 고객인 커뮤니티 매니저들에게 Discourse라는 제품의 USP(독점적 판매 제안)를 추가하는 경우 말입니다. 음.. 클라우드 호스팅 구독을 선택하는 경우라면요.

이 관점에서 Discourse(회사)는 가치 부가 서비스를 제공하여 구독을 더 매력적으로 만들 수 있습니다. 예를 들어, 서로 다른 커뮤니티의 매니저들이 서로의 커뮤니티를 풍요롭게 하기 위해 파트너십과 협력을 적극적으로 찾는 탐색 및 매칭 서비스입니다. 이 서비스는 누구나 접근할 수 있거나, 유료 플랜 고객만 접근할 수 있을 수 있습니다.

그들이 그렇게 하기를 원할까요? 왜 그것이 목표여야 합니까? ActivityPub 프로토콜은 많은 다른 애플리케이션이 다양한 도메인에서 모든 수준에서 상호 운용되도록 허용합니다. 각 프로젝트/앱/제품은 자신의 목표를 추구하며, 상용 소프트웨어의 경우 자신의 USP를 추구합니다.

첫 번째 부분이 중요합니다. 연동을 현명하게 선택하세요. 그렇게 함으로써 제품의 정체성을 모두 잃는다면, 완전한 연동은 절대로 목표가 되어서는 안 됩니다.

우선 '연동(federation)'과 ‘페디버스(the fediverse)’ 사이에는 차이가 있습니다. ActivityPub를 사용하여 연동을 구축하면 원하는 대로 작동하도록 구축할 수 있습니다. 페디버스와 통합하는 것을 목표로 구축한다면,事物가 어떻게 작동하는지에 대한 확립된 사실상 표준이 있습니다. 페디버스 전체 차원의 사용자 수준 밴은 불가능하며, 특정 인스턴스에 대한 밴은 각 인스턴스의 모더레이터의 결정에 기반하여 차단 및 허용 목록에 설정됩니다. 이러한 목록은 종종 공유되며(애드블로커 목록처럼), 특정 인스턴스가 페디버스 전체에서 완전히 차단되는 결과를 초래할 수 있습니다(‘그들은 페디버스의 변방으로 밀려난다’).

이 개념을 설명하는 좋은 비디오는 다음과 같습니다:

포럼과 마찬가지로, 페디버스 내의 각 연동 인스턴스는 모더레이션됩니다. 그리고 저는 그것이 좋은 일이라고 생각합니다. 여전히 완전한 자유가 있습니다. 왜냐하면 무엇이든 가능한, 모더레이션이 없는 자신의 포럼/서버 인스턴스를 시작할 수 있기 때문입니다. 다른 사람들은 그 근거로 당신을 차단할 자유가 있습니다.

4개의 좋아요

커뮤니티 관리 위임

이것은 다소 자유로운 브레인스토밍이고, 마침 이 주제인 자원봉사 커뮤니티 매니저 모집 :mega:   …를 보고 있다가 이런 생각이 들었습니다:

→ 만약 커뮤니티 관리가 연동(federated)된다면?

새로 설치된 Discourse 포럼의 신참 커뮤니티 매니저라고 가정해 봅시다. 관리자 인터페이스와 커뮤니티 구축 실무에 완전히 초보자인 상황입니다. 만약 특정 기간 동안 경험 많은 커뮤니티 매니저를 불러, 조언을 구하고 옆에서 지켜봐 달라고 요청할 수 있다면 어떨까요?

이제 여러분이 이렇게 말할 것 같다는 걸 압니다: “그 포럼에 스태프 계정을 만들면 되지… 연동은 필요 없어!” 그리고 여러분은 맞습니다. 하지만 상황을 반전시켜 좀 더 흥미롭게 만들어 보겠습니다: 만약 제가 제 Discourse 및 커뮤니티 관리 기술을 자원봉사자 또는 전문가(즉, 유료)로서 제공하고 싶다면?

저는 '고객 포트폴리오’에서 최대한 많은 커뮤니티를 생산적으로 처리하고 싶어 할 것입니다. 이는 세 가지 이점을 가져옵니다:

  • 신규 커뮤니티 매니저는 온보딩 서비스를 받아 더 빠르게 시작할 수 있습니다.
  • 커뮤니티 매니저는 자신의 커뮤니티를 넘어 더 광범위하게 자신의 기술에서 이점을 얻을 수 있습니다.
  • 위 두 가지 항목은 Discourse가 제품에 또 다른 차별화 요소(USP)를 추가했다는 것을 의미합니다.

그렇다면 이것이 어떻게 보일까요? 저는 잘 모르겠습니다.. 많은 가능성이 있습니다. 각 제안에서 _위임된 관리자(delegated admin)_는 연동을 통해 자신의 포럼 포털에서 작업하며, 잠재적으로 여러 커뮤니티를 관리합니다:

  • 위임된 관리자는 포럼 설정을 변경하고, 플러그인/컴포넌트/CSS를 설치할 수 있으며, 이는 실제 관리자가 승인한 후에야 적용됩니다.
  • 위임된 관리자는 스태프 전용 카테고리와 그룹에 접근할 수 있으며, 조언을 제공하기 위해 토론에 참여합니다.
  • 위임된 관리자는 포럼에서 발생한 플래그를 처리하며, 이 경우 플래그가 달린 주제만 그들의 포털로 연동됩니다.
  • 위임된 관리자는 커뮤니티 환경을 파악하고 있어, 다른 커뮤니티와의 파트너십 구축 및 콘텐츠 공유를 돕습니다.

위 내용에서 다음을 고려해 보세요:

이것도 가치 부가 서비스가 될 수 있으며, 위 내용과 결합할 수 있습니다. 관련된 모든 당사자는 위임된 관리자가 일정 수준 이상으로 좋은 커뮤니티 매니저로 검증되기에 관심이 있습니다. Discourse(회사)는 (유료) 구독에 있는 사람들에게만 위임된 관리자가 될 수 있도록 허용할 수 있습니다. Discourse 또는 파트너는 커뮤니티 관리 과정을 제공하여, 이를 통과하면 @codinghorror의 승인 도장이 찍힌 자격증을 받을 수 있도록 할 수 있습니다.

음.. 이 아이디어를 좋아하시든 싫어하시든. 제게는 멋진 브레인스토밍 세션이었습니다, 하하 :grinning_face_with_smiling_eyes:
아마 여러분이 더 잘할 수 있을까요?


편집:

Discourse 자체도 이 서비스를 사용할 것입니다. 유료 구독 시작 시, Discourse 팀의 한 멤버가 우리 포럼의 스태프 일원이 되어 같은 종류의 도움을 제공했습니다. 이를 통해 그들은 자신의 원격 '조종석(cockpit)'에서 그렇게 할 수 있거나.. 위임할 수 있습니다.

커뮤니티의 일부를 공유하는 것과 관련된 또 다른 사항.. Meta에서 특정 도움을 요청하는 주제를 게시할 때 여러 번, 해당 주제가 비공개로 설정되었습니다(때로는 민감한 정보가 포함되어 있었기 때문) 그리고 Discourse 팀이 '지원 티켓’으로 처리했습니다. 연동이 있다면 Meta의 지원 부분을 제 자신의 포럼에 통합할 수 있을 것입니다.

4개의 좋아요

(포맷팅은 제 것입니다.) @JE-FF 님의 그 정의가 정말 마음에 들고, ‘커뮤니티에는 경계가 없다’ / ‘디스코스라는 직물’ 개념을 취하는 혁신적인 접근 방식에 완벽하게 부합합니다. 다만 @Mevo 님에게도 언급했듯이, 디스코스가 빅테크 소셜 미디어에 실제로 도전해야 하는지에 대해서는 의문이 듭니다. 원한다면 도전할 수도 있지만, 그럴 필요는 없습니다. 디스코스는 그 자체로 이미 상당한 성공을 거두었으며, 현재는 다중 테넌트 SaaS, 즉 ‘독립적인 커뮤니티 포럼의 클라우드’라는 다른 위치를 차지하고 있기 때문입니다. 그럼에도 불구하고 커뮤니티 개념을 테넌트 경계를 넘어 확장한다면, 포럼과 소셜 미디어 공간 모두에서 경쟁사들에 대해 더 나은 위치를 확보할 수 있을 것입니다.

2개의 좋아요

@aschrijver, 정말 감사합니다. 설명이 매우 명확하고, 솔직히 당신이 하신 말씀에 거의 전적으로 동의합니다. 저는 당신이 제안하신 것이 궁극적인 목표로 "완전(하고 완전히 열린) federation"을 향해 나아가는 "스텝스톤(발판)"이라는 어떤 식의 생각을 머릿속에 품고 메시지를 작성했습니다. 하지만 지금 보니 그 생각이 어디서 나온 것인지 저도 확신이 서지 않으며, 사실 당신은 그런 말을 한 적이 전혀 없을 수도 있습니다. 제 오해(혹은 제가 만들어낸 생각)이거나, 다른 사람들이 한 말을 혼동한 것일 수도 있습니다.

ActivityPub를 사용하면 할 수 있는 모든 것을 허용하되, 여전히 어떻게 일을 처리할지는 스스로 선택할 수 있다는 점, 네, 이 모든 것은 저에게 놀랍게 들립니다. ActivityPub와 Fediverse 사이에 혼란이 있을 수 있다는 당신의 말씀이 옳은 것 같습니다. (다른 주제에서 ActivityPub에 대해 이미 설명해 주셨습니다).)

개인적으로 당신이 가져온 모든 아이디어를 좋아합니다. 연합 기반 "커뮤니티 관리"의 경우, 그렇게 하면 모더레이터에 접근할 수 있는 것도 매우 유용할 수 있습니다. 커뮤니티가 뜨거워질 때나, 예를 들어 더 많은 모더레이터가 필요한 특별한 이벤트가 있을 때 임시로 사용할 수 있는 모더레이터 말입니다. (이 모든 것은 당신의 마음속에서 "커뮤니티 관리"에 포함되었을 수도 있습니다. 당신은 플래그에 대해 말씀하셨습니다. 하지만 "커뮤니티 매니저"를 다른 역할로 정의한다면, "모더레이터"나 "커뮤니티 매니저"뿐 아니라 “관리자(admin)” 유형의 사람들에 대한 접근도 동일하게 가질 수 있습니다.)

이전에 언급했듯이, 이 모든 것은 플러그인과/또는 사이드 사이트(side site)를 통해 “부수적으로” 달성할 수 있습니다. 커뮤니티에서 직접 일하는 사람들이 서비스 목록을 제공하고 제안하는 “프리랜스” 사이드 사이트가 있을 수 있습니다. ActivityPub 덕분에 원격으로 모든 것을 원격으로 집계하여 관리할 수 있는 자체 플랫폼을 갖는 것만큼 멋지지는 않지만, 이미 좋은 시작이 될 것입니다.

결국 이 모든 것은 Discourse 팀이 이러한 아이디어 중 일부를 Discourse에 직접 구현하기를 원하느냐 마느냐에 달려 있습니다.

4개의 좋아요

저는 이 부분에 동의하지 않습니다. 저는 다중 사이트(multi site) 설정을 사용하여 디스코르스(Discourse) 인스턴스의 그룹 소유를 촉진해 왔습니다. 이를 통해 가까운 그룹이 더 큰 커뮤니티와의 직접적인 연결을 유지하면서 자체 스태프가 될 수 있습니다. 제 생각에, 커뮤니티 경계를 유연하게 다루는 것은 ‘보충성 원칙(subsidiarity)’을 활용하여 커뮤니티를 강화하는 것입니다. 즉, 의사결정이 실제 업무에 가능한 한 가깝게 이루어진다는 원칙입니다.

첫째, 그의 발언을 "일종의 '스태프 통제’가 없으면 유저들이 문제를 일으킬 것이다"라고 해석하는 것 같은데, 내 생각엔 그게 그가 한 말이 아닙니다. 둘째, 그는 단순히 "완전히 다른 커뮤니티 동향"에 대해 언급했을 뿐, 그것이 좋거나 나쁘다고 판단하지 않았습니다. 오히려 당신이 "좋은 일"이라고 말하면서 (아직도 "다르다"는 전제 하에) 그의 의견에 동의하는 것처럼 보입니다.

하지만 이 토론의 주제는 그게 아니었습니다. 이 “통제” 문제나 유저들에 대한 문제점이 논점의 핵심이 아니었습니다.

네, 대부분은 다양한 옵션의 폭이 얼마나 넓고, 특정 시나리오에 맞춰 조정할 수 있는 유연성이 얼마나 큰지를 보여주기 위한 것이었습니다. ActivityPub라는 공에만 집중한다면, 연동(federation) 기능을 구현하는 개발자에게는 완전한 ‘공 컨트롤’을 허용합니다. 구현된 사용 사례들은 모두 동등하게 유효한 것들입니다(제품 개발의 일부로 의도적으로 설계되었다는 전제 하에).

@hellekin의 사례가 스펙트럼의 완전한 자유 쪽에는 해당하지 않는다는 점에 동의하며, 이에 대해 더 자세히 논의해 볼 가치가 있다고 생각합니다. @hellekin은 저보다 더 많은 포럼을 다룹니다. 또한 SocialHub 포럼에서 볼 수 있듯이 창의적인 방식으로 포럼을 운영하고 있습니다. 여기에서는 각 ActivityPub 소프트웨어 팀이 포럼의 특정 섹션을 직접 관리합니다. 이러한 팀들은 종종 자체적으로 독립적인 포럼(예: Mastodon의 경우)을 별도로 운영합니다. 자신들이 개발한 소프트웨어에 내장하는 맞춤형 연동 확장 기능에 대해 AP 커뮤니티가 최신 정보를 공유할 수 있도록 ‘이중 작업’을 수행하도록 장려해야 합니다. 그 외에도 SocialHub에는 위성 포럼이라고 할 수 있는 것들이 있습니다.

3개의 좋아요

결국 또 하나의 Discourse 포럼에 가입하기로 결정했습니다. 다른 포럼의 주제에 대해 유용한 조언을 (복사/붙여넣기로) 제공하고 도움을 주기 위해서죠. 관리해야 할 Discourse 사용자 계정이 하나 더 늘었습니다.

해당 포럼은 Fedeproxy로, 코드 포지(Github, Gitlab, Gitea 등의 저장소)를 서로 동기화하는 것을 목표로 하는 새로운 ActivityPub 프로젝트입니다. Forgefed 프로토콜의 구현체가 될 수도 있으며, 여기에서 언급할 가치가 있는 이유는 두 가지입니다:

  1. ActivityPub 연동(federation)의 혜택을 크게 누릴 수 있는 완전히 다른 비즈니스 도메인의 또 다른 사례입니다.
  2. Discourse에 연동 지원이 있다면 이 포럼의 #development 카테고리가 SocialHub의 #software 하위 카테고리와 양방향으로 동기화될 수 있어, 두 포럼에서 작업을 하거나 토론을 중복할 필요가 없습니다.

업데이트:

Fedeproxy 포럼에서 한 사용자(참고로 이 사용자는 여기 가입할 의사가 없었고, 단지 게시물 하나만 남기기 위해 방문했습니다)가 커뮤니티를 위한 흥미로운 링크드 데이터(Linked Data) 온톨로지인 SIOC Core Ontology Specification을 알려주었습니다. 여기서 SIOC 프로젝트는 _“Semantically-Interlinked Online Communities(의미적으로 연결된 온라인 커뮤니티)”_를 의미합니다. 이 온톨로지는 링크드 데이터에서 다음과 같은 의미를 정의합니다:


여기서 언급하는 이유는 비즈니스 도메인/어휘를 중심으로 생각하는 방식을 강조하며, 브레인스토밍에 영감을 줄 수 있기 때문입니다. :slight_smile:

(P.S. SIOC 명세书中的 "Semantic Web(시맨틱 웹)"이라는 용어에 현혹되지 마세요. 그것은 이 프로젝트의 주제가 아닙니다. 너무 복잡하기 때문입니다. 대신 특정 도메인을 정의하기 위한 닫힌(closed) 링크드 데이터 어휘를 찾는 것이 목적입니다.)

업데이트 2:

오늘 Discourse와 유사한 도메인의 훌륭한 프로젝트를 발견했고, 그곳에서 "커뮤니티에는 경계가 없다(Community has no boundary)"는 제목의 토론을 시작했습니다:

PubPub는 Knowledge Futures Group의 일부이며, 이 그룹은 오픈 분산 지식 그래프 프로젝트인 Underlay도 개발하고 있습니다. (이 프로젝트는 Discourse 포럼에서 지식을 집계하는 것에 대한 제 아이디어와 매우 유사합니다.)

업데이트 3:

커뮤니티에 대한 토론은 Discourse에만 국한되지 않고 훨씬 더 광범위하다는 것을 깨달았습니다. 커뮤니티 개념은 우리 사회 전반에 걸쳐 매우 보편적이기 때문입니다. 페디버스(Fediverse)를 위해 커뮤니티 도메인의 표준화와 이를 기반으로 한 ActivityPub 확장 모델링에 대한 토론을 시작했습니다:

7개의 좋아요

Activitypub은 좋은 아이디어이지만, 이를 일급 시민(first-class citizen)으로 구현하는 완전히 새로운 소프트웨어조차도 사양의 여러 결함을 수정해야 하는 상황이므로, 우리에게는 기다려 보는 것이 합리적입니다.

또한, 특정 그룹이 이 기능에 대해 매우 열정적이라면 플러그인으로 충분히 구현할 수 있습니다.

13개의 좋아요

chat-integration 앱에 해당 통합 기능을 pull request로 제출하여, 자격 증명을 추가한 후 태그/카테고리/멘션으로 간단히 크로스 포스팅할 수 있다면 정말 좋겠습니다. 감사합니다!

7개의 좋아요

Thank you @codinghorror. Yes, indeed in the ActivityPub spec there are holes. But they are more-or-less deliberately present, both because the spec authors didn’t want to create an all-inclusive huge and complex technology standard, plus - at the time of witing - they didn’t know how the spec would evolve. So they waited for reference implementations (this also had some drawback, like e.g. Mastodon using a custom client API instead of the Client-to-Server part of the spec, but Mastodon also defined some real handy namespace extensions to be used).

Currently most of these holes have been filled in by other open standards (though there are still some to be plugged). There’s HTTP Signatures for Server-to-Server federation (or - less used - JSON-LD signatures), for federated user mentions Webfinger is used. Client-to-Server uses OAuth2 Client Credentials and there are de-facto specs NodeInfo / NodeInfo2 to communicate server capabilities.

I agree that a great number of things discussed in this thread (the majority probably) can be implemented using Plugins and the great Discourse API’s. It would as @sunjam says indeed be awesome if someone would venture there :slight_smile:


Derived from this brainstorm I have initiated some more general discussions on the SocialHub forum, that I’d like to refer to:

Update 2021/03/07: On SocialHub in the topic on creating a Community vocabulary AP extension, I elaborated a bit more on how Discourse would fit into a community model. See my post:

7개의 좋아요