채팅용 Matrix 프로토콜

코드를 GitHub에 공개했지만, 현재는 알파 버전 수준의 품질이라고 볼 수 있습니다. 많은 부분이 작동하지만, 플러그인에는 문서화가 부족하고 Discourse에서 이를 작동시키기 위해 몇 가지 패치(예: 이 패치)가 더 필요합니다.

https://github.com/udan11/discourse-chat-matrix

현재까지 구현된 기능:

  • 홈서버 탐색 – 작동 :white_check_mark:
  • 채널 – 작동 :white_check_mark:
  • 그룹 채팅 – 작동 :white_check_mark:
  • 다이렉트 채팅 – 작동 :white_check_mark:
  • 수정 – 작동 :white_check_mark:
  • 삭제 – 작동 :white_check_mark:
  • 업로드 – 다음 단계로 예정
  • 접속 상태/입력 중 알림 및 읽음 확인 – 다음 단계로 예정 (가능한 경우)
  • 이모지 반응 – 작동 :white_check_mark:
  • 답장 – 작동 :white_check_mark:
  • 텍스트 메시지 (평문 및 서식 지정, 이모지) – 작동 :white_check_mark:

베타 품질에 도달하면 플러그인 출시를 알리는 더 공식적인 토픽이 생성될 예정입니다. 이 플러그인에 관심을 가져주셔서 감사합니다!

37개의 좋아요

http://matrix.org/Element.io는 더 이상 존재하지 않습니다(물론 http://element.io는 존재합니다).

1개의 좋아요

잘하셨지만, 이 메시지는 여기서 묻혀 버릴 겁니다. 이 플러그인을 위한 별도의 테마를 만들어야 합니다.

1개의 좋아요

테마라고 하면 무슨 뜻인가요? (최상위 유형 주제라는 뜻이었나요?)

1개의 좋아요

@volanar 저는 댄이 말한 요점을 놓친 것 같습니다:

그는 원하는 노출 수준을 원할 때 새로운 스레드를 시작할 충분한 역량을 갖추고 있습니다. :smiling_face:

5개의 좋아요

아마도 부끄러운 질문일 수 있지만, 이 통합을 통해 Discourse에서 e2ee(종단 간) 암호화를 제공하게 될까요? 아니면 단순히 Discourse에 있는 내용을 복사하여 Matrix로 전송하는 방식일까요? 만약 후자라면, Discourse의 관리자가 채팅에서 전송된 모든 평문 메시지에 여전히 접근할 수 있게 되나요?

1개의 좋아요

정말 신나네요. 링크된 풀 리퀘스트가 완료된 걸 봤는데, 아마도 아주 큰 프로젝트일 거예요. Matrix 채팅 지원이 어떻게 진행되고 있는지 궁금하고, 기대가 큽니다.

8개의 좋아요

이 스레드가 더 이상 활성화되지 않은 것 같지만, 그래도 답글을 남기고 안부를 전하고 싶었습니다. 여전히 이 스레드를 가끔씩 확인하는 사람이 있다는 걸 알려드리고 싶어요 :slight_smile:

14개의 좋아요

다른 사람들이 더 쉽게 찾고 논의할 수 있도록 이 내용을 별도의 플러그인 섹션으로 분리해 주실 수 있을까요? 검토해 주셔서 감사합니다!

3개의 좋아요

제 이해로는 Discourse는 주로 공개 포럼으로 설계된 것입니다. 이 관점에서 E2E 암호화는 오히려 역효과를 낼 수 있습니다. Discourse 인스턴스의 관리자를 신뢰하지 못한다면, 아예 사용하지 않는 것이 나을 것입니다. E2E 암호화로는 관리자가 암호화를 우회하기 위해 브라우저에 악성 기능을 주입하는 것을 막을 수 없습니다. 1:다수 또는 다수:다수 통신에 기밀성 요구 사항이 높다면, 제 생각에는 전용 Matrix 채널이 최선의 선택입니다.

4개의 좋아요

동의합니다. 인터넷을 사용하는 대부분의 사람들이 플랫폼의 사설 채팅이 관리자によって 종종 볼 수 있다는 점을 완전히 이해하지 못하고 있다고 추측합니다. 제 경우처럼 관리자가 된다면, 제가 모든 1:1 메시지를 읽을 수 있다는 것을 아무리 설명해도 사람들이 이해하지 못할 것 같아서, Discourse에서 사설 채팅을 그냥 비활성화할 것 같습니다. 그리고 사람들이 직접적으로 연락하고 싶다면 Matrix나 Signal을 통해 하도록 유도할 수도 있겠네요 (아직 사용자명이 없어서 전화번호를 모든 사람에게 알려주지 않아도 됩니다).

오픈소스 Discourse의 경우, 관리자가 E2EE를 그냥 깨뜨릴 수 있으므로, 어쨌든 신뢰할 수 없을 수도 있다는 지적에는 감사드립니다.

답장 주셔서 감사합니다~

정말 멋지지만, 실제 설치 지침이 나열되어 있지 않은 것 같습니다.

이 플러그인에 대한 추가 정보 및 [Meta](https://meta.discourse.org/t/TODO)에서의 설치 방법.

혼동하고 계신 것 같습니다. 이 기능은 Matrix로 브리징하는 것이므로 어떤 형태의 E2E 암호화도 포함하지 않습니다. 단순히 포럼 채팅을 Matrix 사용자들도 이용할 수 있게 할 뿐입니다.

이것은 기밀성과는 아무런 관련이 없습니다. 단순히 Matrix에 있는 사람들과 채팅하기 위한 것입니다.

여기에는 E2E가 없습니다. E2E란 서버에 도달하기 전에 클라이언트 측에서 암호화가 이루어진다는 뜻입니다. Matrix 지원과 E2E를 혼동하지 말아 주시겠습니까?

Discourse에서 E2E를 원하고 다른 곳에서 논의하기를 원하는 분들을 위해… Discourse Encrypt (deprecated) 을 사용하실 수 있습니다.

3개의 좋아요

이 문제는 모든 관리자를 각 채팅 그룹의 참여자 목록에 포함시켜서(물론 관리자가 퇴장하거나 입장할 때 동적으로 관리되도록) 비교적 간단하게 해결할 수 있지만, 물론 이는 별도의 기능 요청(FR)이 될 것입니다.

1개의 좋아요

바퀴를 다시 발명하고 있는 건지 모르겠지만, 저는 Discourse Chat을 다른 플랫폼으로 연결하는 브릿지를 개발하고 있습니다. 텔레그램에서는 꽤 좋은 성과를 거두었고, 브리징도 정말 잘 작동하고 있습니다. 다음으로 고려 중인 것은 Discourse Chat을 Matrix로 연결하는 것입니다.

9개의 좋아요

좋네요. 개발 중인 기존 브릿지를 살펴볼 수 있습니다. 그것도 작업할 가치가 있을 수 있습니다. GitHub - udan11/discourse-chat-matrix: A Matrix bridge for Discourse Chat · GitHub

4개의 좋아요

약간 그렇습니다. 이 스레드는 Discourse 채팅 프로토콜을 Matrix 프로토콜로 대체하자는 아이디어로 시작되었습니다. Matrix 프로토콜은 잘 설계되어 있고 채택률이 높아지고 있는 것 같으므로 매우 합리적인 것처럼 들립니다. 왜 여기서 브리지에 대해 이야기하는지 저도 모르겠습니다. 질문은 Discourse 프로토콜이 미래에 비추천(deprecated)되어야 하는지, 아니면 그렇지 않은지에 관한 것입니다.

개인 채팅/메시지에 대한 E2EE(개인용 암호화)는 Matrix 프로토콜을 채택하면 기본적으로 가능할 것입니다. 커스텀 프로토콜이 필요 없습니다.

4개의 좋아요

디스코어 코어 팀에서 "디스코어 채팅과 매트릭스 기반 채팅 간의 상호 운용성"에 관한 논의의 현재 상태에 대해 정보를 제공해 주실 수 있나요? 유럽에서는 이미 여러 주요 기업이 자사 메신저 앱의 기술적 기반으로서 매트릭스를 사용하고 있습니다:

매트릭스 도입은 전 세계적으로 확대되고 있습니다. 디스코어 채팅을 매트릭스 생태계와 "연결"하는 것이 향후 디스코어 플랫폼 사용의 중요한 논거가 될 수 있다고 생각합니다 (마스토돈과 디스코어를 연결하는 ActivityPub와 유사한 방식). 다음 주소에 일부 브리지 코드가 있습니다:

하지만 마지막 활동은 2년 전입니다. 이 코드를 채택하거나 “공식적으로 지원되는” 새로운 것을 만들 계획이 있는지 궁금합니다.

10개의 좋아요

ActivityPub가 공개된 토론을 연결하는 데 유용하지만, Matrix 프로토콜을 구현하면 다른 디스코스 서버 간 비공개 카테고리를 안전하게 연결하는 수단으로도 사용할 수 있으며, 사용자에게 알림을 보내는 추가적인 방법으로도 활용할 수 있습니다.

4개의 좋아요

나토(NATO)도 마찬가지입니다: Reddit

1개의 좋아요

현재 구체적인 계획은 없습니다.

저희는 해당 저장소에서 볼 수 있는 초기 탐색 단계에서 Dan과 협력하여 채팅이 Matrix와 상호 운용 가능하도록 만드는 것이 실현 가능한지 더 알아보기 위해 노력했습니다.

당시에는 유망해 보였지만, 완전히 해결하지 못한 몇 가지 도전 과제가 있었습니다. 그 중 가장 큰 문제는 각 시스템에서 사용자가 처리되는 방식이었습니다.

그 이후로 채팅도 상당히 발전했으며, 저희는 Matrix 호환성을 설계의 제약 조건으로 다루지 않아 두 시스템 사이에 추가로 해결해야 할 차이점이 있을 수 있습니다.

이 작업을 계속 추진하고 구축된 것을 유지할 더 강한 동기를 확보하려면 이 작업을 후원하는 누군가가 필요할 것입니다.

7개의 좋아요