Nostr 릴레이란? 초보자를 위한 설명

모든 Nostr 메시지는 릴레이를 통해 전달됩니다. 당신의 클라이언트는 서명된 이벤트를 릴레이로 보내고, 다른 사용자의 클라이언트는 릴레이에서 이벤트를 가져옵니다. 모든 포스트, 좋아요, 팔로우, DM에 대해 이를 반복합니다. 릴레이는 화려한 구성 요소는 아니지만, 네트워크가 작동하게 만드는 구성 요소입니다.

이 가이드는 릴레이가 실제로 무엇인지, 무엇을 하고 하지 않는지, 그리고 어떤 릴레이가 당신의 사용에 중요한지 생각하는 방법을 다룹니다.

요약. 릴레이는 WebSocket을 통해 서명된 Nostr 이벤트를 수락하고, 저장하고, 구독자에게 전달하는 작은 서버입니다. "그" Nostr 릴레이는 없습니다. 네트워크는 조정하지 않는 수천 개의 독립적인 릴레이로 이루어져 있습니다. 당신의 클라이언트는 동시에 여러 개에 연결되며, 그 합집합이 당신의 네트워크 뷰입니다.

준비되면, @nostr.blog 주소 받기 →

릴레이가 하는 일

세 가지 일, 모두 간단합니다.

이벤트 수락. 클라이언트가 WebSocket 연결을 열고 서명된 JSON 객체를 포함한 EVENT 메시지를 보냅니다. 릴레이는 서명을 확인하고(청구된 pubkey와 일치하는지), 선택적으로 정책(스팸, 속도 제한, 차단 목록)에 대해 확인하고, 수락하거나 거부합니다. 수락된 이벤트는 저장소로 이동합니다.

이벤트 저장. 릴레이는 로컬 데이터베이스(보통 SQLite 또는 PostgreSQL)를 사용하여 이벤트 ID, 저자 pubkey, 종류, 태그 값으로 인덱싱합니다. 이를 통해 구독 필터에 효율적으로 응답할 수 있습니다.

구독 제공. 클라이언트가 필터를 포함한 REQ 메시지를 보냅니다("이 저자들의, 이 종류의, 이 타임스탐프 이후의 이벤트를 주세요, 100으로 제한"). 릴레이는 데이터베이스에서 일치하는 저장된 이벤트를 쿼리하고 스트리밍한 후 EOSE(저장된 이벤트의 끝)를 보내고 구독을 열린 상태로 유지합니다. 필터와 일치하는 모든 새로운 이벤트는 실시간으로 클라이언트에 푸시됩니다.

이것이 약간의 변형이 있는 전체 릴레이 API입니다. 릴레이는 다른 아무것도 하지 않습니다. 순위 매기기, 추천, 자신의 정책을 넘어선 중재, 릴레이 간 조정이 없습니다.

릴레이가 하지 않는 일

릴레이가 이론상으로 할 수 있지만 보통 하지 않는 여러 가지가 있습니다.

다른 릴레이와 대화. 릴레이는 독립적입니다. 서로 동기화하지 않습니다. 포스트가 릴레이 A에는 있지만 릴레이 B에는 없다면, B에서만 읽는 누군가는 그것을 보지 못합니다. 복제는 릴레이가 서로 미러링하기 때문이 아니라 클라이언트가 여러 릴레이에 포스팅하기 때문에 발생합니다.

전역 규칙 적용. 각 릴레이는 자신의 규칙을 가집니다. 하나가 거부하는 것을 다른 것은 수락합니다. 전역 정책 권한은 없습니다.

오프체인 청구 검증. 릴레이는 서명된 이벤트를 수락하지만, NIP-05 필드의 "alice@example.com"이 실제로 이벤트의 pubkey에 매핑되는지 확인하지는 않습니다. 그것은 클라이언트의 일입니다.

플랫폼으로 행동. 릴레이는 홈페이지, 피드 또는 브랜드가 있는 웹사이트가 아닙니다. 백엔드입니다. 사용자는 직접 릴레이와 상호작용하지 않으며, 클라이언트가 합니다.

왜 이 설계가 특이한가

대부분의 네트워크는 많은 일을 하는 서버를 가지고 있습니다. Mastodon 인스턴스는 단순한 릴레이가 아니라 사용자, 프로필, 타임라인, 중재 도구, 관리 대시보드가 있는 완전한 Twitter 같은 웹 애플리케이션입니다. XMPP 서버는 사용자, 방, MUC, pubsub를 가집니다. Matrix 홈서버는 무거운 소프트웨어입니다.

Nostr의 릴레이는 의도적으로 최소한입니다. 릴레이는 사용자가 누구인지 알지 못합니다(릴레이에 사용자 계정 없음). 릴레이는 콘텐츠를 소유하지 않습니다(콘텐츠의 진정성은 저장한 사람이 아니라 서명에서 옵니다). 릴레이는 연합하지 않습니다(다른 릴레이와의 프로토콜 수준의 조정 없음).

이러한 최소성이 릴레이가 많은 이유입니다. 릴레이를 운영하는 것은 저렴합니다. $5/월 VPS는 수백 명의 활동 사용자를 서빙하는 릴레이를 실행할 수 있습니다. Mastodon 인스턴스 운영과 비교하면, 비슷한 규모에서는 훨씬 더 많은 리소스와 유지 보수가 필요합니다.

기본 릴레이 대 사용자 정의 릴레이

모든 Nostr 클라이언트는 기본 목록과 함께 제공됩니다. 2026년 기준 일반적인 항목:

• wss://relay.damus.io (Damus 운영, 대용량)
• wss://nos.lol (커뮤니티 운영, 무료)
• wss://relay.primal.net (Primal 운영)
• wss://offchain.pub (커뮤니티, 안정적)
• wss://relay.nostr.band (집계 중심)
• wss://nostr.wine (유료, 스팸 필터링)

이것들은 대부분의 사용자에게 작동합니다. 처음 세 개가 일일 트래픽의 대부분을 처리합니다. 이를 대체할 필요는 없습니다. 이유가 있지 않는 한요. (nostr.blog를 통해 가입한 경우, 큐레이션된 기본 릴레이 목록이 이미 구성되어 있으며, 나중에 설정에서 조정할 수 있습니다.)

사용자 정의 이유:

• 성능. 지리적으로 더 가까운 릴레이가 더 빠릅니다. 아시아에 있다면 아시아 기반 릴레이를 추가하면 읽기가 빨라집니다.
• 개인정보. 특정 대형 릴레이가 당신의 구독 패턴을 보길 원하지 않는다면 다른 릴레이를 사용하세요.
• 주제 전문화. 일부 릴레이는 특정 주제나 커뮤니티에 중점을 둡니다. 이들에 연결하면 그 콘텐츠에 대한 노출이 증가합니다.
• 스팸 허용도. 스팸으로 넘쳐난다면, 스팸 필터링된 유료 릴레이가 구독 가치가 있을 수 있습니다.

몇 개의 릴레이를 사용해야 하나요

3개 또는 4개가 보통 적절한 수입니다. 더 많다고 항상 더 좋은 것은 아닙니다.

너무 적음(1-2). 단일 릴레이 가동 중단이 당신의 포스트를 일시적으로 침묵시킵니다. 충분한 중복성이 없습니다.

적절함(3-6). 당신의 포스트가 충분히 많은 곳에 도달하여 가동 중단이 중요하지 않습니다. 클라이언트가 여러 릴레이에서 쿼리를 경쟁시킬 수 있어 읽기 성능이 좋습니다.

너무 많음(10+). 각 릴레이는 지연 시간과 데이터 전송을 추가합니다. 클라이언트는 모두를 쿼리해야 하며, 느린 것이 전체 피드를 지연시킵니다. 배터리와 대역폭이 상당한 이득 없이 증가합니다.

확실하지 않으면 기본값을 사용하세요. 특별한 이유를 추구한다면 증분적으로 조정하세요.

릴레이 정책이 중요합니다

모든 릴레이는 무엇을 수락할지에 대한 불문의 또는 명시된 규칙을 가집니다. 대부분은 관대하고, 일부는 엄격합니다. 몇 가지 일반적인 정책 유형:

쓰기 개방, 읽기 개방. 누구나 포스팅할 수 있고, 누구나 읽을 수 있습니다. 대부분의 커뮤니티 릴레이.

쓰기 유료, 읽기 개방. 포스팅하려면 작은 요금을 지불합니다. 누구나 당신의 포스트를 읽을 수 있습니다. 대부분의 유료 릴레이. 스팸을 극적으로 줄입니다.

화이트리스트. 승인된 계정만 포스팅할 수 있습니다. 회사 또는 커뮤니티 릴레이에 사용됩니다.

주제 필터링. 특정 기준(해시태그, 종류, 길이)과 일치하는 이벤트만 수락합니다.

지역 제한. 특정 지역의 사용자만 수락합니다. 드뭅니다.

릴레이에 의존하기 전에 그 명시된 정책(보통 /.well-known/nostr.json 또는 릴레이의 정보 엔드포인트)을 확인하세요. 당신의 포스팅 패턴이 릴레이의 정책과 일치하지 않으면 쓰기가 조용히 실패합니다.

자신의 릴레이 운영

놀랍게도 쉽습니다. 기본 설정:

1. VPS를 임대합니다($5/월 범위가 좋습니다).
2. 릴레이 구현을 설치합니다. strfry와 nostream은 두 가지 일반적인 오픈 소스 선택입니다.
3. 포트 443 또는 8080을 엽니다. DNS를 서버로 지정합니다.
4. 릴레이를 시작합니다.

총 시간: Linux에 익숙한 사람을 위해 1시간 이하. 기본적으로 복잡한 구성이 필요 없습니다. 당신 자신이나 작은 커뮤니티를 위해 릴레이를 운영하면 네트워크에 복원력을 더하고 당신의 Nostr 데이터의 일부에 대한 명시적 제어를 제공합니다.

이에 대한 전용 가이드는 run-your-own-relay에 있습니다.

릴레이와 개인정보

연결한 각 릴레이는 다음을 봅니다:

• 당신의 IP 주소
• 당신이 구독하는 필터(어떤 pubkey를 읽는지, 어떤 해시태그를 보는지)
• 당신의 포스트(여기에 포스팅했기 때문에 내용)
• 당신의 활동 타이밍

릴레이는 보지 못합니다:

• 암호화된 DM의 내용(암호문만)
• 당신의 개인 키

릴레이 수준의 메타데이터 누출을 최소화하려는 사용자:

• Tor 또는 VPN을 사용합니다.
• 여러 릴레이에 읽기를 분산하여 누구도 전체 그림을 보지 못하도록 합니다.
• 다양한 구독 유형에 대해 릴레이를 회전하는 클라이언트를 사용합니다.

대부분의 사용자는 이 중 어느 것도 필요하지 않습니다. 프로토콜의 개인정보 모델은 릴레이가 반신뢰 반공개 인프라라고 가정합니다. 당신의 활동 패턴을 그들로부터 숨기도록 설계되지 않았습니다.

릴레이 선택: 간단한 규칙

새로운 경우: 기본값을 유지하세요.

구체적으로 무언가에 답답한 경우(스팸, 속도, 신뢰성): 답답한 것만 변경하세요. 하나 또는 두 개의 릴레이를 추가하거나, 당신을 괴롭히는 것을 바꾸세요.

고급인 경우: 의도적으로 큐레이션합니다. 당신의 필요(지역, 주제, 신뢰 수준)를 충족하는 4-6개의 릴레이를 선택하고 신중하게 관리하세요.

편집증적인 경우: 단일 운영자가 당신의 전체 활동을 보지 못하도록 충분한 독립적 릴레이에 분산합니다. Tor를 사용합니다. 지역을 혼합합니다.

잘못된 이동은 더 좋은 것이 낫다고 바라면서 수십 개의 릴레이를 추가하는 것입니다. 느린 클라이언트와 낭비된 대역폭이 결과이며, 더 나은 경험이 아닙니다.