Hacker News 의견

• 내가 보기엔 Stalwart는 훌륭한 JMAP 서버임
  JMAP은 이메일 클라이언트를 만들기에 아주 좋은 프로토콜이라고 생각함
  직접 호스팅은 피하고 싶지만, Stalwart를 클라이언트의 서버 컴포넌트로 써서 기존 IMAP 데이터를 동기화하고 JMAP API로 접근할 수 있다면 흥미로울 것 같음
  IMAP-IMAP 동기화 같은 방식이 가능하다고 들었는데, 혹시 Stalwart로 시도해본 사람이 있는지 궁금함
  이런 접근이 가능해지면 기존 IMAP 메일박스를 JMAP으로 접근할 수 있게 되어, 새로운 세대의 이메일 클라이언트 개발이 촉진될 것 같음
  • “excellent”라는 표현이 과장이 아님을 강조하고 싶음
    Stalwart는 정말 아름답게 구조화된 소프트웨어임
    신뢰를 쌓으며 점진적으로 완성도를 높여온 점이 인상적임
    게다가 거의 한 명의 개발자가 주도했다는 사실이 놀라움
    GitHub 기여자 그래프
  • IMAP ↔ IMAP 동기화 도구인 mbsync를 쓰면 간단히 구현 가능함
    원격 IMAP을 Stalwart의 로컬 IMAP 서버로 주기적으로 동기화하면, Stalwart가 내부적으로 이를 JMAP으로 변환해 제공함
    처음엔 maildir 단계를 거쳐야 할 줄 알았는데, IMAP ↔ IMAP만으로 충분히 가능해 보임
  • 이런 걸 오랫동안 기다려왔음
    지금까지 찾은 건 너무 비싸서, 이런 발전이 반가움
  • 나도 같은 이유로 고민 중이었음
    아직 결과물은 없지만 계속 생각 중임
• “클라이언트가 없다”는 말을 많이 보는데, 당연히 서버 구현이 먼저 나와야 함
  Stalwart가 사실상 JMAP의 첫 서버 구현이라 이제 클라이언트를 만들 이유가 생긴 셈임
  참고로 Mozilla의 새 메일 서비스도 JMAP을 사용할 예정이라, 큰 추진력이 될 것 같음
  • Stalwart가 진짜 게임 체인저가 될 수도 있다고 생각함
    예전엔 Nextcloud나 SoGo 같은 그룹웨어를 써봤지만 실망스러웠음
    그런데 이제 Nextcloud가 Stalwart와 협력하고, Opencloud와 Mozilla/Thunderbird도 JMAP을 통합 중이라 기대됨
    특히 Thunderbird의 웹메일 프로젝트 Stormbox도 진행 중이라 흥미로움
    지금은 Big Tech에서 벗어나려는 흐름이 강해, 타이밍도 완벽함
  • 참고로 Stalwart는 JMAP의 연락처와 캘린더를 처음 구현한 서버임
    Cyrus는 JMAP 메일만 지원했음
  • FastMail은 이미 JMAP을 실서비스에 사용 중이며, RFC 공동 저자이기도 함
  • 최근 Pimsync에 JMAP 캘린더 동기화를 구현했음
    이제 CalDAV, JMAP, 파일시스템 간 동기화가 가능함
  • JMAP 클라이언트는 존재함
    나는 aerc라는 클라이언트를 사용 중임
• JMAP은 웹 API 설계 측면에서 매력적이지만, 모든 새로운 프로토콜이 HTTP 위에서만 만들어져야 하는지는 의문임
  파일 공유, 그룹웨어, 메일, 캘린더 같은 건 JSON 오버헤드 없이 더 효율적으로 설계할 수도 있을 것 같음
  그래도 HTTP 기반 설계에는 분명 이유가 있겠지 싶음
  • 이메일은 원래 바이너리 프로토콜이 아니었음
    대부분의 초기 인터넷 프로토콜이 텍스트 기반 Telnet 위에서 만들어졌기 때문임
    HTTP/3는 본질적으로 바이너리 프로토콜이고, JSON은 구조적이고 압축 효율이 좋아서 실제로 꽤 효율적임
    “JSON over HTTP”는 “custom text over telnet”보다 미묘하지만 확실한 개선임
  • 직접 직렬화 포맷을 만들면 오히려 문제만 늘어남
    capnproto, grpc, ASN.1 같은 프레임워크를 써도 각각의 복잡함이 있음
    JSON은 단순하고 한계가 명확해서 다루기 쉬움
    반면 Microsoft Exchange 프로토콜처럼 구현에 종속된 설계는 장기적으로 문제를 낳음
  • HTTP 위에 얹는 게 항상 좋은 건 아님
    경우에 따라 TCP가 아닌 다른 프로토콜이 더 나을 수도 있음
    개인적으로 JSON은 싫고, DER 포맷이 더 낫다고 생각함
    Gemini, Scorpion 같은 “small web” 프로토콜도 흥미로움
  • 이메일을 HTTP로 가져오는 데 드는 오버헤드는 크지 않음
    오히려 웹 클라이언트 호환성 측면에서 HTTP가 유일한 선택임
    HTTP를 안 쓰는 이점은 거의 없다고 봄
  • HTTP/2, HTTP/3는 이미 바이너리 프로토콜임
    JSON 대신 CBOR을 쓰면 페이로드도 바이너리화 가능함
    HTTP는 상태 전송(state transfer) 프로토콜이라 동기화에 적합함
    여기에 Braid 확장을 추가하면 상태 동기화(state synchronization) 프로토콜로 확장 가능함
    나는 Braid 프로젝트에서 일하고 있음
• Fastmail이 JMAP의 캘린더와 연락처 부분을 빨리 구현하길 바람
  메일은 이미 지원하지만, 아직 CardDAV/CalDAV를 병행해야 함
  • 현재 내부적으로 오래된 JMAP 버전을 사용 중임
    10년 전 작성한 caldav_sync 코드가 아직 돌아가고 있음
    최근에는 objectid 생성 로직을 개선해 ID 크기를 줄이고 정렬성을 높였음
    이제 최신 JMAP 스펙으로 캘린더와 연락처를 업데이트할 예정임
    파일 시스템은 시간이 좀 더 걸릴 듯함
  • JMAP Calendar 스펙은 아직 정식 승인되지 않음
    초안 문서 참고
    Contacts는 RFC 9610으로 10개월 전에 승인됨
  • Thunderbird, K-9 Mail, iPhone 메일 앱 등 주요 클라이언트가 지원하지 않으면 JMAP은 확산되기 어려움
    기존 솔루션 대비 어떤 문제를 해결하는지도 명확하지 않음
• JMAP은 좋은 프로토콜이지만 클라이언트 지원이 부족함
  Apple Mail, Thunderbird, Outlook 같은 주요 클라이언트가 지원해야 함
  Canary나 Spark 같은 소규모 클라이언트가 차별화 포인트로 도입해도 좋을 텐데 의외로 안 함
  • Outlook은 이미 MS365 전용으로 바뀌는 중임
    새 Outlook은 모든 데이터를 Azure에 저장하고, 실제 서버와는 프록시로 통신함
    JMAP을 지원할 가능성은 거의 없음
  • JMAP은 웹메일 같은 얇은 클라이언트에는 좋지만, 로컬 상태를 저장하는 데스크톱 앱에는 큰 이점이 없음
  • 주요 메일 제공자가 지원하지 않으면 JMAP의 차별점이 약함
    (IMAP을 옹호하는 건 아님)
  • 서버 지원이 먼저 필요함
    Gmail이나 iCloud가 지원하지 않으면 클라이언트를 만들어도 의미가 적음
    듀얼 지원은 가능하겠지만, 시장이 좁음
  • JMAP이 성공하려면 메일뿐 아니라 캘린더, 연락처, 파일 공유 등 통합 그룹웨어 프로토콜로 발전해야 함
    하지만 그건 아직 많은 “if”가 남은 이야기임
• Stalwart 덕분에 이메일 셀프호스팅이 훨씬 쉬워졌음
  완전 통합형 서버라 새로운 시대가 열린 느낌임
  Maddy도 괜찮지만 유지보수는 덜 활발함
  • 나도 Maddy+Postfix+Dovecot+Rspamd 조합에서 Stalwart로 옮기는 중인데, 문서 품질이 부족하다고 느낌
    옵션과 기본값, 상호 관계를 한눈에 볼 수 있는 문서가 없음
    Web UI 설정은 가능하지만 선언적 배포와 충돌함
    .toml 파일이 읽기 전용이면 오류가 발생함
  • 쓸만한 JMAP 웹메일 클라이언트가 있는지 궁금함
    FastMail이나 Topicbox 외에는 마땅한 게 없음
    Roundcube나 Wildduck처럼 HTTPS로 셀프호스팅 가능한 게 필요함
  • Postfix+Dovecot 대비 실질적 이점이 있는지 모르겠음
    “Rust로 새로 썼다” 외에는 뚜렷한 차별점이 없어 보임
• Sieve를 JSON 기반으로 대체하려는 건 아닌지 걱정됨
  좋은 MUA(메일 클라이언트)가 없는 상황에서 JMAP이 도움이 될지 의문임
  서버는 이미 해결된 문제지만, 클라이언트는 정체되어 있음
  IMAP4의 기능조차 대부분 구현되지 않았고, Sieve 클라이언트도 형편없음
  • “서버는 해결된 문제”라는 말엔 동의하지 않음
    Dovecot은 아직 UTF-8도 완벽히 지원하지 않음
    Stalwart 같은 프로젝트가 이런 레거시 한계를 극복하려는 시도임
    클라이언트도 Apple Mail처럼 발전한 사례가 있음
  • 결국 서버와 클라이언트 둘 다 필요함
    둘 중 하나만 발전해선 의미가 없음
    이제 좋은 서버가 생겼으니, 남은 건 좋은 클라이언트임
• Google Workspace나 Outlook 환경에서 JMAP 스타일의 JSON API를 원한다면 Nylas가 대안이 될 수 있음
  Nylas는 강력하지만 가격이 높음
  대규모에서는 계정당 월 $1.50이라 SaaS 마진에 영향을 줄 수 있음
  그래도 실시간 이메일 분석이나 커스텀 UI 구축에는 매우 유용함
• Stalwart를 설치해봤는데, 웹서버와 메일서버가 통합되어