Parley: 일반 IRC 클라이언트로 쓰는 분산형 채팅

AI 요약

Parley는 여러 인스턴스가 연결되는 분산형 채팅 서비스입니다. 이번 변경은 서로 다른 인스턴스에서 같은 별명을 쓰는 사용자가 같은 채널에 있을 때, 멘션 알림이 의도하지 않은 계정에도 전달되던 버그를 고칩니다.

별명과 도메인으로 수신자 판별

기존 namesAccount는 메시지에서 별명이 단독으로 등장하면 멘션으로 처리했습니다. 콜론도 단어를 끝내는 문자로 취급해 bob:bar.com: lunch?처럼 도메인을 붙여 특정 사용자를 지목해도, foo.com과 bar.com의 두 bob에게 모두 알림이 갔습니다. bar.com에서 보낸 bob: lunch? 역시 bar.com의 bob을 가리키지만 foo.com의 bob까지 깨웠습니다.

수정안은 수신자를 발신자가 본 표기대로 해석합니다. bob:bar.com은 [email protected]과 마찬가지로 bar.com의 bob을 가리킵니다. 도메인 없는 bob은 발신자 자신의 인스턴스에 있는 계정을 뜻하므로, 발신자가 로컬 사용자일 때만 해당 인스턴스의 bob에게 알림을 보냅니다. alice:bar.com이나 [email protected] 안에 있는 bar는 멘션으로 보지 않습니다.

이름을 도메인과 함께 해석할 때는 현재 인스턴스의 도메인이나 피어 인스턴스의 도메인만 인정합니다. 클라이언트가 사용자에게 보여준 닉네임 표기를 처리하면서 bob:D, bob:10 같은 문자열은 기존처럼 bob이라는 이름으로 읽습니다. 알림 판별 함수 pushConsidered는 호출자가 이미 보유한 s.mu 잠금 아래에서 피어 목록 s.peers를 확인합니다.

검증과 바뀐 동작

두 인스턴스에 bob 계정을 하나씩 만든 통합 테스트 TestOnlyTheBobThatWasMeantIsPushed를 추가했습니다. 다섯 가지 메시지에서 지목한 bob에게만 알림이 가는지 검사하며, 수정 전 main에서는 bar.com의 bob에게 잘못 알림이 전송되는 첫 사례부터 실패합니다. 이름 해석을 확인하는 TestANameMeansWhoTheSenderWasShown 테스트도 추가했습니다.

make test는 -race 옵션과 함께 통과했고, 새 통합 테스트는 연속 10회 통과했습니다. bte check parley.bt는 오류 0건과 기존과 같은 경고 7건을 보고했으며, bte fmt는 파일을 변경하지 않았습니다. 의도적으로 바뀐 동작도 있습니다. 다른 인스턴스의 사용자가 여기 있는 계정을 도메인 없는 별명만으로 부르면 더는 알림을 보내지 않습니다. 발신자 화면에서는 그 별명이 발신자 쪽의 다른 사용자를 가리키기 때문입니다.

Hacker News 반응

• @davidcollantes — Parley는 중앙이 없는 채팅 네트워크입니다. 각 개인이나 팀이 자기 도메인에 작은 인스턴스를 운영합니다. 인스턴스는 DNS와 well-known 신원 문서를 이용해 서로를 찾고, 서명한 메시지를 HTTPS로 주고받습니다. Lurker, Mango, mIRC, WeeChat, Textual 같은 일반 IRC 클라이언트에서 플러그인 없이 연합 네트워크 전체를 보여줍니다.
  • @altilunium — 직접 인스턴스를 운영하지 않는 일반 사용자도 그냥 쓸 수 있나요?
  • @davidcollantes — 네. 계정을 만들어줄 인스턴스 운영자를 알고 있어야 합니다.
  • @grim_io — 그러니까… 안 된다는 거죠? :)
  • @jagged-chisel — 직접 인스턴스를 운영하지 않아도 다른 사람의 인스턴스를 이용해 시험해볼 수 있습니다.
  • @NoboruWataya — 프로토콜이 인기를 얻으면 다른 연합 서비스처럼 누구나 가입할 수 있는 공개 인스턴스가 생길 것 같습니다. 일반 사용자가 Mastodon에 가입하는 건 X에 가입하는 것만큼 쉽습니다. 일반 사용자가 그렇게 하지 않는다는 건 별개의 문제입니다.
  • @davidcollantes — 직접 운영하지 않고 시험해보고 싶은 분들은 제게 이메일을 보내주세요. 주소는 david dot collantes at gmail dot com입니다.
  • @someonebaggy — 이 글을 AI가 만든 요약인가요?
• @myaccountonhn — 꽤 마음에 들지만 스팸이 금세 문제가 될 것 같습니다.
  • @davidcollantes — 늘 걱정해야 하는 문제입니다. 스팸을 보내는 사용자와 인스턴스 전체를 차단할 수 있습니다.
• @shreddit — 바로 이런 걸 지난 몇 주 동안 생각했지만, 직접 구현하기엔 제가 너무 멍청했습니다. 인스턴트 메시징만을 위한 이메일 같네요.
  • @yvdriess — 아주 오래전에 MSN을 설치하기 싫어서 mIRC 봇으로 메시지를 주고받았는데, 이것도 그때를 떠올리게 하네요.
  • @Athas — 그리 오래전도 아닌 시절까지 Bitlbee를 썼습니다. 여러 채팅 프로토콜을 연결하는 IRC 데몬이었죠. 특히 XMPP로 독점 채팅 서비스에 접속할 수 있던 시절에는 예상보다 훨씬 잘 작동했습니다. 그 서비스들에 관심을 끊고 나서야 사용을 멈췄습니다.
  • @doubled112 — 요즘은 Slack과 WhatsApp을 연결한 Matrix 홈 서버를 운영해 채팅 클라이언트 수를 줄였습니다. Matrix 클라이언트 상황은 좀 덜 복잡했으면 합니다.
  • @zaik — 운이 좋으시네요. 이미 누군가 이 문제를 생각해 IETF에 RFC를 제출하고 구현까지 했습니다. XMPP라고 합니다.
• @padolsey — 흥미롭지만, 경고받아온 봇 무리가 나타나기에도 지나치게 편리해 보입니다.
• @okwhateverdude — 하하, XMPP인데 XML 대신 IRC를 쓰는 거군요. 알겠습니다.
  • @singpolyma3 — TCP와 XML 대신 HTTP와 JSON을 씁니다. IRC는 프런트엔드일 뿐이라 어떤 프런트엔드든 쓸 수 있습니다.
• @aunderscored — 흥미롭네요. 왜 공개 링크 네트워크를 쓰지 않나요? 결과 상태는 비슷할 겁니다. 스팸은 일반적으로 문제가 될 테고, 백엔드가 다르면 기존 도구를 활용하기도 어려울 겁니다. & 채널은 재미있네요. 그 부분을 마주한 봇과 클라이언트 중 얼마나 많은 수가 멈춰버릴지도 궁금합니다. IRC 역사에 그런 사례가 있죠.
  • @someonebaggy — IRC 링크 방식은 스패닝 트리를 요구하는 점 등을 포함해 엉망입니다. RFC의 서버 간 프로토콜을 실제로 쓰는 서버가 하나도 없어서, 비공식 프로토콜 중 하나를 골라야 합니다. 차라리 용도에 맞는 프로토콜을 새로 만드는 편이 낫습니다.
• @someonebaggy — 바이브 코딩으로 만든 건가요?
• @user2722 — 개인정보 문제 때문에 채팅방을 두 종류로 나누는 계획을 세운 적이 있습니다. 일반 채팅은 서버에만 존재하고, 사용자를 거치지 않고 서버 간에 대화 기록을 유출하지 않습니다. 공개 대화방은 한 서버에 두고 누구나 MQTT로 구독할 수 있는 전역 채널입니다. 계획 단계에서 끝났지만, 연합 채팅방과 일반 채팅방을 분리해 IRC의 공개성과 폐쇄성을 함께 유지하는 방식이 흥미롭다고 생각했습니다.
  • @Fastidious — 이 프로젝트도 비슷한 것 같습니다. &room은 로컬이고 #room은 연합됩니다.
• @singpolyma3 — 그러면 방은 내 호스트가 우연히 알고 있는 호스트 사이에서만 ‘전역’인가요? 그럼 계속 넷스플릿이 벌어지고, 누군가를 차단할 수 있는 사람은 서버 관리자뿐이겠네요.
• @Conlectus — LLM 기반 개발의 구체적인 단점은 기존 분야의 작업을 살펴보지 않은 채 새 프로젝트에 깊이 빠질 수 있다는 점입니다. 이 경우에는 XMPP의 절반을 허술하게 명세해 구현한 것과 같습니다. LLM이 언젠가 그 점을 언급했을 법하지만 저장소에는 그런 내용이 없습니다.

원문: Git Mills / 번역·요약: Trawling