BeeBuzz: 종단 간 암호화가 가능한 자체 호스팅 푸시 알림 서비스 및 PWA 클라이언트

몇 달 전 저는 몇 가지 필수 기능을 갖춘 간단한 알림 서비스를 찾고 있었습니다. 바로 오픈 소스여야 하고, 자체 호스팅이 가능해야 하며, E2E 암호화를 지원하고, 네이티브 앱 없이 크로스 플랫폼을 지원해야 했으며, 제가 직접 개발하는 애플리케이션과 서비스에서 사용할 수 있도록 API/SDK가 제공되어야 했습니다.

기존 옵션들을 찾아봤지만, 당시에는 제가 원하는 모든 것을 충족하는 것을 찾지 못했습니다. 어떤 프로젝트는 제가 필요로 하는 것보다 훨씬 많은 기능을 수행했고, 어떤 것은 네이티브 앱을 요구했으며, 또 다른 것들은 암호화나 호스팅 방식에서 차이가 있었습니다.

그래서 저는 가능성을 확인하기 위해 재미와 학습 목적으로 BeeBuzz를 시작하게 되었습니다. 6개월 후에는 Docker Compose로 완전히 자체 호스팅할 수 있는 소규모 알림 전용 서비스가 되었고, 모바일과 데스크톱을 위한 브라우저/PWA 클라이언트, CLI, Go SDK, HTTP API, 웹훅(webhooks), 그리고 Home Assistant 통합 기능까지 갖추게 되었습니다.

암호화는 설계의 주요 부분이 되었습니다. 각 장치는 페어링 과정에서 자체 키 쌍(key pair)을 생성하며, BeeBuzz와 공유되는 것은 공개 키(public key)뿐입니다. 발신자가 클라이언트 측 암호화(client-side encryption)를 지원하는 경우, 알림 콘텐츠는 BeeBuzz에 도달하기 전에 age를 사용하여 암호화되므로, 서버는 암호화된 콘텐츠만 처리합니다. 개인 키(private key)는 장치에 보관됩니다.

일반 웹훅과 같이 전송 전에 암호화할 수 없는 통합의 경우에도, BeeBuzz는 여전히 신뢰 기반 전달(trusted delivery)을 사용할 수 있습니다. 따라서 이 아이디어는 모든 곳에서 E2E를 강제하는 것이 아니라, 실제로 의미가 있는 곳에 사용하는 것이었습니다.

제가 원했던 또 다른 점은 클라이언트를 브라우저/PWA 내부에 유지하여 모바일과 데스크톱에서 동일한 코드베이스로 작동하고 앱 스토어에 의존하지 않는 것이었습니다. BeeBuzz는 현재 베타를 벗어났기 때문에, 이곳에 공유할 가치가 있다고 생각했습니다. 비슷한 필요를 가진 분들에게 유용하기를 바랍니다.

프로젝트의 결정 배경과 아키텍처에 대한 세부 사항이 궁금하다면, 제가 개발 과정에 대해 devlog에 작성했으니 참고해 주시기 바랍니다.

출처: https://codeberg.org/beebuzz/beebuzz 출처 (미러): https://github.com/lucor/beebuzz 문서: https://docs.beebuzz.app AI 면책 조항: https://lucor.dev/projects/#ai 피드백은 언제나 환영합니다. 제출자 /u/lucordev [링크] [댓글]